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

[Bernard]

@Marian

You can tell the windbg to run in secure mode,but this more related to host-target scenario.

[Bernard]

You do not need full memory dump unless you suspect that user mode thread(code) has affected the kernel mode driver(by passing some commands).For the beginning kernel memory dump should be sufficient.

[Marián__VooDooMan__M]

here is my full memory dum 7zip-ed.

[Vitaly_S_Intel]

Marián "VooDooMan" Meravý wrote:

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

Hi Marian! Thanks for your help!

I don't see the file attached to the message - did you post it other way?

[Marián__VooDooMan__M]

due to Inel forum bug I was succesful to upload file, but I was unsuccessful to publish it onto this forum.

I decided to publish it at archive.org, and there is the link: https://archive.org/details/MEMORY.DMP.7z

[Marián__VooDooMan__M]

Vitaly Slobodskoy (Intel) wrote:

Quote:

Marián "VooDooMan" Meravý wrote:

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

Hi Marian! Thanks for your help!

I don't see the file attached to the message - did you post it other way?

Intel's forum has bug, I have attached the file, but it is not seen here. Another bug is false-positive spam detection, so this is my 3rd approach to reply.

So I have uploaded the kernel core dump to archive.org, and there it is: (https:// ) archive.org/details/MEMORY.DMP.7z

Best,

[Bernard]

@Marian

If you have kernel dump file can you upload it?

[Marián__VooDooMan__M]

iliyapolak wrote:

@Marian

If you have kernel dump file can you upload it?

I was trying it few times, but due to "bug" on Intel forum, my posts and uploaded files were classified like a spam :-( .

[Marián__VooDooMan__M]

full memory dump is attached.

[Marián__VooDooMan__M]

dump is attached.

[Peter_W_Intel]

What I can download file, the size is 50.4 MB (52,922,661 bytes) only - I tried several times. 

[Bernard]

@Peter

Is that file freely available to download?

[Peter_W_Intel]

@iliyapolak

Anyone posts an attached file which is public, but I cannot download...I don't know why, maybe file size has exceeded max size, 20MB?

I can get dump file from https://archive.org/details/MEMORY.DMP.7z, and I have escalated this result to dev team. We need to wait because now is holiday season:-)

[Bernard]

@Peter

It seems that when I responded to post #53 the dump file was not uploaded.

I can confirm that I was able to download that file.

Tomorrow I will look at this.

[Bernard]

@Marian

Unfortunately every time when I try to download your dump file the file itself is corrupted.Can you upload it to skydrive?

[Marián__VooDooMan__M]

@iliyapolak

please, use above link to archive.org, since this forum is broken, often my replies are not going to pass due to broken spam filter.

[Bernard]

@Marian

Ok I will download from archive.org.

[Bernard]

@Marian and Peter

After short analysis of the dump file it seems that BSOD is triggered by Windows kernel mode function.

This disassembled line of code  fffff801`82610490 8b02            mov     eax,dword ptr [rdx] ds:00000005`ffd01328=???????? is probably responsible for bringing down the system.By looking at the callstack I suppose that code which has been resolved as a  hal!HalSendSoftwareInterrupt+0x51 is accessing or reading a value at invalid memory location pointed by rdx register.That location could have been paged out prior to the HalSoftwareInterrupt execution thus triggering the BSOD.It is strange because Windows kernel mode code should not either causing page fault of pageable pool or referencing invalid memory address at IRQL == 0x2.VTune vtss.sys can be responsible for calling HalSoftwareInterrupt at IRQL == 0x2,but I do not suppose that driver developer(s) could have know before that referenced paged pool will be either invalid or paged out.

[Bernard]

Tomorrow I plan to spend more time investigating this issue.

[Bernard]

One of the possible workaround could be for example insertion of call to KeLowerIrql() function before the call to HalSendSoftwareInterrupt in order to protect the system against the situation when the  system-level code is about to incur page fault or reference invalid memory at IRQL == DPC level i.e 0x2.

On the assumption that KeRaiseIrql() function calls HalSendSoftwareInterrupt to probably raise/lower IRQL to APC/DPC level.

[Bernard]

@Peter

Can you suggest my check(workaround) which was posted post no. #62  to vtss.sys developer(s) or at least to ask them if this could be helpful in the problem solving?