A bug in vtss.sys

[Slava_I_]

There is a bug in vtss.sys - an attempt to close an invalid handle from the driver, the bug reveales itself only when the driver verifier is active. Mostly it is a nuisance as this bug should not have any impact on the system but the driver verifier must be disabled to use VTune 2013 as Microsoft considers this bug as a fatal error that should be fixed so the driver verifier crashes the system. The following is a crash analysis

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

INVALID_KERNEL_HANDLE (93)
This message occurs if kernel code (server, redirector, other driver, etc.)
attempts to close a handle that is not a valid handle.
Arguments:
Arg1: 0000000000000000, The handle that NtClose was called with.
Arg2: fffff8a0000018b0,
Arg3: 0000000000000000
Arg4: 0000000000000001

Debugging Details:
------------------

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x93

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from fffff80003bbc3c2 to fffff80003abd620

STACK_TEXT:
fffff880`02fd2da8 fffff800`03bbc3c2 : 00000000`00000000 fffffa80`03d1e040 00000000`00000065 fffff800`03b03b10 : nt!RtlpBreakWithStatusInstruction
fffff880`02fd2db0 fffff800`03bbd1ae : 00000000`00000003 00000000`00000000 fffff800`03b006d0 00000000`00000093 : nt!KiBugCheckDebugBreak+0x12
fffff880`02fd2e10 fffff800`03ac56c4 : 00000000`0000001c fffff980`1288efe0 00000000`00000000 00000000`00000000 : nt!KeBugCheck2+0x71e
fffff880`02fd34e0 fffff800`03d2261b : 00000000`00000093 00000000`00000000 fffff8a0`000018b0 00000000`00000000 : nt!KeBugCheckEx+0x104
fffff880`02fd3520 fffff800`03ac4813 : fffff880`02fd3600 00000000`00000000 00000000`00000000 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x51ce4
fffff880`02fd3620 fffff800`03ac0db0 : fffff880`1fe0d3ff 00000000`00000000 fffff800`03c54880 00000000`00240024 : nt!KiSystemServiceCopyEnd+0x13
fffff880`02fd3828 fffff880`1fe0d3ff : 00000000`00000000 fffff800`03c54880 00000000`00240024 fffffa80`0509d4a0 : nt!KiServiceLinkage
fffff880`02fd3830 fffff880`1fe10502 : 00000000`00000000 fffffa80`05184db0 00000000`746c6600 fffff880`02fd3970 : vtss+0x73ff
fffff880`02fd38a0 fffff800`03eadeb7 : fffffa80`05184db0 ffffffff`80001bf0 fffff980`1288efe0 00000000`00000001 : vtss+0xa502
fffff880`02fd39a0 fffff800`03eae2b5 : 00000000`00000010 00000000`00000000 00000000`00000010 00000000`00010202 : nt!IopLoadDriver+0xa07
fffff880`02fd3c70 fffff800`03ad27e1 : fffff880`00000000 ffffffff`80001bf0 fffff800`03eae260 00000000`00000000 : nt!IopLoadUnloadDriver+0x55
fffff880`02fd3cb0 fffff800`03d656fa : ffffffff`ffffffff fffffa80`03d1e040 00000000`00000080 fffffa80`03d065a0 : nt!ExpWorkerThread+0x111
fffff880`02fd3d40 fffff800`03aa3b46 : fffff880`009e6180 fffffa80`03d1e040 fffff880`009f0f40 01e09a41`0c0a3590 : nt!PspSystemThreadStartup+0x5a
fffff880`02fd3d80 00000000`00000000 : fffff880`02fd4000 fffff880`02fce000 fffff880`02fd28b0 00000000`00000000 : nt!KiStartSystemThread+0x16

[Marián__VooDooMan__M]

Marián "VooDooMan" Meravý wrote:

Quote:

iliyapolak wrote:

I would not blame so fast Intel for that "bug".Mainly because there is lack of source code with its private and public symbols or even pdb file so it is hard to see the circumstances or driver code which caused the BSOD.

Absolutely agreed.

Though, Intel developers SHOULD look inside of it. I have also sent to Microsoft kernel dumps via their reporting service included in Windows.

So we will see, it will take some time, and we must be patient.

[Bernard]

Marián "VooDooMan" Meravý wrote:

Quote:

Marián "VooDooMan" Meravý wrote:

Quote:

iliyapolak wrote:

I would not blame so fast Intel for that "bug".Mainly because there is lack of source code with its private and public symbols or even pdb file so it is hard to see the circumstances or driver code which caused the BSOD.

Absolutely agreed.

Though, Intel developers SHOULD look inside of it. I have also sent to Microsoft kernel dumps via their reporting service included in Windows.

So we will see, it will take some time, and we must be patient.

I agree with you,but I fear that Intel policy is to wait for more than one occurrence of the aforementioned error(BSOD) in order to try to fix it.

[Bernard]

VTune vtss.sys also crashed my system.Soon I will analyze full system dump.

[Peter_W_Intel]

@ iliyapolak 

Did it happen when using latest U15? Thank you to report this. Please post your results after analyzing system dump.

Regards, Peter

[Bernard]

It is the latest version of VTune which comes with Parallel Studio XE 2013.The BSOD code is different from those reported here in this thread.Crash occurs immediately when advanced analysis is started.

[Bernard]

I will post more details on tuesday.

By the way,what does U15 stand for?

[Marián__VooDooMan__M]

iliyapolak wrote:

By the way,what does U15 stand for?

Update 15 of VTune.

[Marián__VooDooMan__M]

@Intel: Any update for this rather catastrophic issue? Like time line of releasing U16? I'm waiting impatiently... I guess this bug is in the code really stupid bug that can be resolved by the least code change... as per my own experience my code crashing like this often have "stupid mistake" and it is causing the crash and often needs to adjust just one line of the code...

So I guess, bug causing BSOD might be resolved easily, like just change in 3 lines of code of vtss.sys driver... But I might be wrong, since I do not know deep internals of vtss.sys, nor I have reverse engineered the vtss.sys.

And PLS, timeline for U16, TIA! Though I know Intel employees cannot comment Intel's future plans, but I strongly recommend to change this policy, e.g. like "Microsoft's Tuesday". Please mention this idea at Intel's internal conference. I believe I am not the only one, who is impatient for to wait for next update/release.

[Marián__VooDooMan__M]

It causes BSOD only in case of "advanced" diagnostics, immediately after run of project of with this diagnostics.

[Marián__VooDooMan__M]

Peter Wang (Intel) wrote:

@ iliyapolak 

Did it happen when using latest U15? Thank you to report this. Please post your results after analyzing system dump.

Regards, Peter

Yes, I can confirm it happens using the latest U15.

[Marián__VooDooMan__M]

@Intel: I can post (privately) kernel memory dump. Privately because kernel memory could contain security sensitive data.

@Intel: Can you reproduce this problem? Few users were reporting BSOD, so I guess it is very easy to reproduce it.

[Vitaly_S_Intel]

Please try to use "Advanced Hotspots" with the first option (no context switches, no call stacks) - it shouldn't cause BSOD.

[Bernard]

@Marian

Did you try to update VTune?

[Bernard]

@Peter

It seems that VTune BSOD dump file was not saved on my machine.I will try later to reproduce that bug.

[Bernard]

Marián "VooDooMan" Meravý wrote:

It causes BSOD only in case of "advanced" diagnostics, immediately after run of project of with this diagnostics.

Yes the same situation on my machine.

[Marián__VooDooMan__M]

iliyapolak wrote:

@Marian

Did you try to update VTune?

Hello iliyapolak,

I have U15 installed, so yes, I did.

best,

[Marián__VooDooMan__M]

iliyapolak wrote:

@Peter

It seems that VTune BSOD dump file was not saved on my machine.I will try later to reproduce that bug.

On Windows, you need to have at least 400 MiB swap file on ***system*** drive (e.g. c:\ ), in order to save kernel minidump.

This is because Windows at BSOD needs swap file on ***system*** drive, to write kernel dump into it, and upon next reboot, this page/swap file is moved to error reporting service (truncating it to minidump size), and system creates brend new page/swap file.

best,

[Vitaly_S_Intel]

Marian, iliyapolak, just to check this issue is not connected to upgrade/install somehow, can you please uninstall/install VTune drivers and check again?

> cd <VTune install dir>/bin32

> amplxe-sepreg -u pax

> amplxe-sepreg -i

Also, can you confirm the following command doesn't cause BSOD:

> amplxe-cl -collect advanced-hotspots --duration 5

This is similar to just using "Hotspots" option inside "Advanced Hotspots" analysis type.

[Bernard]

Marián "VooDooMan" Meravý wrote:

Quote:

iliyapolak wrote:

@Peter

It seems that VTune BSOD dump file was not saved on my machine.I will try later to reproduce that bug.

On Windows, you need to have at least 400 MiB swap file on ***system*** drive (e.g. c:\ ), in order to save kernel minidump.

This is because Windows at BSOD needs swap file on ***system*** drive, to write kernel dump into it, and upon next reboot, this page/swap file is moved to error reporting service (truncating it to minidump size), and system creates brend new page/swap file.

best,

I made a mistake and enabled full memory dump(8 GB).Set this to kernel memory dump.

[Marián__VooDooMan__M]

iliyapolak wrote:

Quote:

Marián &quot;VooDooMan&quot; Meravý wrote:

Quote:

iliyapolak wrote:

@Peter

It seems that VTune BSOD dump file was not saved on my machine.I will try later to reproduce that bug.

On Windows, you need to have at least 400 MiB swap file on ***system*** drive (e.g. c:\ ), in order to save kernel minidump.

This is because Windows at BSOD needs swap file on ***system*** drive, to write kernel dump into it, and upon next reboot, this page/swap file is moved to error reporting service (truncating it to minidump size), and system creates brend new page/swap file.

best,

I made a mistake and enabled full memory dump(8 GB).Set this to kernel memory dump.

I really wish to upload 8 GiB full memory dump, but I'm afraid it contains security-sensitive data. I'd be glad if Intel set this topic as "private" i.e. not accessible by other users as this information is proprietary. But I have an idea, clean reboot (w/o running key agents for SSH keys, etc...) and start BSOD analysis and post it there.

[Marián__VooDooMan__M]

@Intel: there is full kernel memory after causing BSOD caused by vtss.sys driver.

I have 8 GiB RAM and 8 GiB of swap space.

I am posting full 8 GiB memory dump, I took attention to running programs in sake if confidentiality, so I hope full memory dump will not contain serurity-sensitive data.

Please, unpack it with 7zip. original filename is C:\Winow\MEMORY.DMP