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

[Peter_W_Intel]

vtss.sys is one of VTune(TM) Amplifier XE 2013 drivers, I don't know why it impacted on your system. You might restart the system (there is no process of using this driver), then uninstall the producrt. Thus, the driver file vtss.sys should be removed from C:\Windows\System32\drivers, even you can remove this file manually if uninstallation didn't succeed. You can reinstall the product if you want to use VTune(TM) Amplifier XE 2013 again. By the way, you may create a new thread on the forum for corresponding product, in this case - visit http://software.intel.com/en-us/forums/intel-vtune-amplifier-xe-and-vtune-performance-analyzer

[Slava_I_]

Peter Wang (Intel) wrote:
I don't know why it impacted on your system.

Hi, The reason is simple - this is an error to provide an invalid handle ( zero in that case ) and in the same time declare the caller as KernelMode ( aka Previous Mode ) - this is just an error so the driver verifier caught the Intel driver. Intel developers should have used the Driver Verifier.

[Vladimir_K_]

I have the same issue with Windows 7 and Vtune AmplifierX 2013 Update 12. The problem is not only with Driver Verifier but with OS - this driver has affect to system stability. After 20 seconds after system has loaded it stalls and not respounding on any interrupts.

Solution is only remove file driver, but I have to work with Vtune. This is the big problem!

[James_T_Intel]

I'm moving this to the correct forum.

[David_A_Intel1]

Hi Vladimir:

Can you please provide your OS information, included build number?  Ideally, you would submit an issue to Intel® Premier Support and attach the output of the 'amplxe-feedback -create-bug-report report.zip' command (i.e., the zip file) to the issue.  Any time there is a suspected "bug", we prefer to troubleshoot the issue with the reported via Premier.  It provides a secure mechanism for sharing information and an audit trail.

[Bernard]

Hi Peter 

Usually  unhandled exception/error in kernel mode will always lead to bug check it is so by the design.

As Slava said the error was related to null value handle.Try to use !handle command or set the Vtune process context to implicit will give a more insight into the probable reason of bug check.It is also recommended to run Verifier to catch such a bugs.

[Peter_W_Intel]

Thanks iliyapolak.

I have escalated this to developer to know if it is a known issue. If you met this again, please do what Mr.Anderson asked in 09/13/2013. Your log file will be helpful for problem investigating.

Thanks, Peter 

[Bernard]

Hi Peter you are welcome

As handles are created probably by the Object Manager passing a null handle could be a failure of OS kernel mode code which is responsible for handles.

[Bernard]

Vladimir K. wrote:

I have the same issue with Windows 7 and Vtune AmplifierX 2013 Update 12. The problem is not only with Driver Verifier but with OS - this driver has affect to system stability. After 20 seconds after system has loaded it stalls and not respounding on any interrupts.

Solution is only remove file driver, but I have to work with Vtune. This is the big problem!

Hi Vladimir sorry but I did not understand your problem.Is it related to Driver Verifier?Could you explain that?

[levicki]

@Ilya:

Problem is with a buggy vtss.sys driver whose developers do not follow Microsoft driver writing and testing practices.

I just had this driver cause a BSOD even though I did not even use VTune at the moment. I will be sending minidump and other info to Jennifer via email and I hope this will be fixed.

Also it is unforgivable that VTune uninstaller does not remove this driver but it leaves it running on the system.

Finally, vtss.sys file has no version information resource and for casual users it might not be clear where it came from and whether it part of a legitimate software or malware.

[Bernard]

Thanks Igor for informing me.Can you send me kernel dump file.Full kernel dump if possible.

Thanks in advance.

[Marián__VooDooMan__M]

I have similar problem, and I accidentally created dupe at http://software.intel.com/en-us/forums/topic/496323#comment-1774740 , <- there is my kernel backtrace from WinDbg, but I cannot send kernel dump, since it might contain sensitive data.

[Marián__VooDooMan__M]

I have upgraded to Vtune amp XE 2013 Update 15, and post-mortem WinDbg is saying:

[plain]

STACK_TEXT:  
ffffd000`38606638 fffff802`0475f7e9 : 00000000`0000000a 00000005`ffd01334 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
ffffd000`38606640 fffff802`0475e03a : 00000000`00000000 ffffe000`061c6880 00000000`00000000 ffffd000`38606780 : nt!KiBugCheckDispatch+0x69
ffffd000`38606780 fffff802`04d8d490 : 00000000`00000206 fffff802`046b0056 ffffe000`00537180 ffffe000`036fa880 : nt!KiPageFault+0x23a
ffffd000`38606910 fffff800`030c2a89 : ffffd000`207ce180 ffffe000`061c6880 fffff802`048f4180 00000000`00000000 : hal!HalSendSoftwareInterrupt+0x51
ffffd000`38606980 ffffd000`207ce180 : ffffe000`061c6880 fffff802`048f4180 00000000`00000000 fffff802`048f4180 : vtss+0x10a89
ffffd000`38606988 ffffe000`061c6880 : fffff802`048f4180 00000000`00000000 fffff802`048f4180 fffff800`030c2991 : 0xffffd000`207ce180
ffffd000`38606990 fffff802`048f4180 : 00000000`00000000 fffff802`048f4180 fffff800`030c2991 ffffe000`061c6880 : 0xffffe000`061c6880
ffffd000`38606998 00000000`00000000 : fffff802`048f4180 fffff800`030c2991 ffffe000`061c6880 00000000`00000000 : nt!KiInitialPCR+0x180

STACK_COMMAND:  kb

FOLLOWUP_IP:
vtss+10a89
fffff800`030c2a89 ebd6            jmp     vtss+0x10a61 (fffff800`030c2a61)

[/plain]

My config: fully-patched Win 8.1 Pro x64. I hope this helps.

[Bernard]

@Marian

That dump confirms that vtss driver referenced pageable kernel memory while executing at DPC level(0x2).It is forbidden by design for driver to generate page fault while executing at DPC level.I am not an expert on Windows kernel programming,but I think that driver should query current IRQL level before accessing pageable memory.

[Bernard]

I do not exclude scenario where BSOD was caused by this function  hal!HalSendSoftwareInterrupt+0x51

[Marián__VooDooMan__M]

iliyapolak wrote:

I do not exclude scenario where BSOD was caused by this function  hal!HalSendSoftwareInterrupt+0x51

Surely, everything is possible but the miracle. But it is more than clear (at 99%) that there is a bug in Intel's kernel driver.

[Bernard]

Probably it is rather not a bug,but lack of caution when programming a driver for kernel mode operation.We need to wait for an input from Intel developers in order to confirm what I am suspecting.

[Marián__VooDooMan__M]

iliyapolak wrote:

Probably it is rather not a bug,but lack of caution when programming a driver for kernel mode operation.We need to wait for an input from Intel developers in order to confirm what I am suspecting.

What *WE* are suspecting is IMHO Intel's bug.

Maybe Intel developers were checking VTune on Win 7 (or older), but not our BSOD that exhibits on Win 8.1 x64 .I am planning to use various combinations VTune configurations on my Win 8.1 Pro x64 system, and I plan to report them here, i.e. the successful result or BSOD.

@Intel: @staff:I can provide confidential kernel dump if you will need it (as a confidential file, since full memory dump a really contains sensitive data)) seen only by staff, not by public forum.

[Bernard]

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.

[Marián__VooDooMan__M]

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.