Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Etienne_K_
Beginner
227 Views

vtss.sys led to a blue screen on Windows 10

hi,

whilst running the CPUz stress-test (http://www.cpuid.com/softwares/cpu-z.html) my system unexpectedly froze and the following bluescreen notified me that the culprit might have been vtss.sys:

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000094, Exception code that caused the bugcheck
Arg2: fffff80017192b72, Address of the instruction which caused the bugcheck
Arg3: ffffd00135eb3370, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

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


SYSTEM_SKU:  SKU

SYSTEM_VERSION:  System Version

BIOS_DATE:  07/25/2014

BASEBOARD_PRODUCT:  SABERTOOTH X79

BASEBOARD_VERSION:  Rev 1.xx

BUGCHECK_P1: c0000094

BUGCHECK_P2: fffff80017192b72

BUGCHECK_P3: ffffd00135eb3370

BUGCHECK_P4: 0

EXCEPTION_CODE: (NTSTATUS) 0xc0000094 - {EXCEPTION}  Integer division by zero.

FAULTING_IP: 
vtss+12b72
fffff800`17192b72 c3              ret

CONTEXT:  ffffd00135eb3370 -- (.cxr 0xffffd00135eb3370)
rax=0000000000020000 rbx=fffff800a6d7a1f0 rcx=0000000000001004
rdx=0000000000080004 rsi=000000003f0f4a01 rdi=0000000000020001
rip=fffff80017192b72 rsp=ffffd00135eb3d98 rbp=0000000000000401
 r8=ffffe0013f0f4a01  r9=ffffe0013f0f4a60 r10=ffffd0012ede6260
r11=ffffd00135eb3de8 r12=ffffd00135eb43a0 r13=0000000000080004
r14=0000000000000286 r15=0000000000001004
iopl=0         nv up di pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00000002
vtss+0x12b72:
fffff800`17192b72 c3              ret
Resetting default scope

CPU_COUNT: c

CPU_MHZ: c82

CPU_VENDOR:  GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 2d

CPU_STEPPING: 7

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

BUGCHECK_STR:  0x3B

PROCESS_NAME:  cpuz_x64.exe

CURRENT_IRQL:  0

ANALYSIS_VERSION: 10.0.10240.9 amd64fre

LAST_CONTROL_TRANSFER:  from fffff8001718f543 to fffff80017192b72

STACK_TEXT:  
ffffd001`35eb3d98 fffff800`1718f543 : fffff800`a6d7a1e0 fffff800`163ab8c6 ffffd001`35eb43a0 ffffe001`00000001 : vtss+0x12b72
ffffd001`35eb3da0 fffff800`a6ed7ebd : fffff800`a6d7a1f0 ffffd001`35eb4150 ffffe001`3e4adac0 00000000`00000002 : vtss+0xf543
ffffd001`35eb3e30 fffff800`a6ed5390 : ffffe001`392fd840 00000000`00000000 ffffe001`378b3701 ffffd001`35eb40b0 : nt!PspInsertThread+0x63d
ffffd001`35eb4050 fffff800`a6ed4f79 : ffffd001`35eb4420 ffffd001`35eb4920 00000000`00000001 ffffd001`35eb43e0 : nt!PspCreateThread+0x288
ffffd001`35eb4310 fffff800`a6b75863 : 00000000`00000000 fffff800`a6ed2e9e 00000000`0048fe78 00000000`0000000c : nt!NtCreateThreadEx+0x201
ffffd001`35eb4a90 00007ffe`f365402a : 00007ffe`f02898b6 00000000`00000001 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0048f998 00007ffe`f02898b6 : 00000000`00000001 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtCreateThreadEx+0xa
00000000`0048f9a0 00007ffe`f15abc5c : 00000000`00000004 00000001`40083250 00000000`00000120 00007ffe`f02c2c0f : KERNELBASE!CreateRemoteThreadEx+0x276
00000000`0048fe20 00000001`40022f8a : 00000000`00000005 00000001`7ee52e84 00000000`00000000 00000000`00000000 : KERNEL32!CreateThreadStub+0x3c
00000000`0048fe70 00000001`40002d87 : 00000000`00d19810 00000000`00000000 00000000`00d19810 00000000`ffffffff : cpuz_x64+0x22f8a
00000000`0048ff20 00007ffe`f15a2d92 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : cpuz_x64+0x2d87
00000000`0048ff60 00007ffe`f35c9f64 : 00007ffe`f15a2d70 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x22
00000000`0048ff90 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x34


FOLLOWUP_IP: 
vtss+12b72
fffff800`17192b72 c3              ret

SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  vtss+12b72

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: vtss

IMAGE_NAME:  vtss.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  55c4d1c4

STACK_COMMAND:  .cxr 0xffffd00135eb3370 ; kb

BUCKET_ID_FUNC_OFFSET:  12b72

FAILURE_BUCKET_ID:  0x3B_vtss!Unknown_Function

BUCKET_ID:  0x3B_vtss!Unknown_Function

PRIMARY_PROBLEM_CLASS:  0x3B_vtss!Unknown_Function

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0x3b_vtss!unknown_function

FAILURE_ID_HASH:  {739a51cd-f64b-01d1-9bcb-25792e387d80}

Followup:     MachineOwner
---------

6: kd> lmvm vtss
Browse full module list
start             end                 module name
fffff800`17180000 fffff800`17242000   vtss       (no symbols)           
    Loaded symbol image file: vtss.sys
    Image path: \SystemRoot\system32\drivers\vtss.sys
    Image name: vtss.sys
    Browse all global symbols  functions  data
    Timestamp:        Fri Aug 07 17:41:56 2015 (55C4D1C4)
    CheckSum:         00020719
    ImageSize:        000C2000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4

 

I am using the latest Intel Parallel Studio XE 2016 Prof. and have a 33GB memorydump for you should it be necessary.

 

0 Kudos
15 Replies
Bernard
Black Belt
227 Views

Can you run .cxr 0xffffd00135eb3370  command in order to display exception context?

 

Bernard
Black Belt
227 Views

Can you run also following command: ln fffff800`17192b72 and this one u@rip and this ub@rip L8,  these will display call stack around faulting IP (RIP register)

 

 

Etienne_K_
Beginner
227 Views

Sorry for opening two posts, but one post was kept in moderation for some reason...

6: kd> ln fffff800`17192b72
Browse module
Set bu breakpoint
6: kd> u @rip
nt!KeBugCheckEx:
fffff800`a6b6b240 48894c2408      mov     qword ptr [rsp+8],rcx
fffff800`a6b6b245 4889542410      mov     qword ptr [rsp+10h],rdx
fffff800`a6b6b24a 4c89442418      mov     qword ptr [rsp+18h],r8
fffff800`a6b6b24f 4c894c2420      mov     qword ptr [rsp+20h],r9
fffff800`a6b6b254 9c              pushfq
fffff800`a6b6b255 4883ec30        sub     rsp,30h
fffff800`a6b6b259 fa              cli
fffff800`a6b6b25a 65488b0c2520000000 mov   rcx,qword ptr gs:[20h]
6: kd> ub @rip L8
nt!KiBugCheckReturn:
fffff800`a6b6b234 e807000000      call    nt!KeBugCheckEx (fffff800`a6b6b240)
fffff800`a6b6b239 90              nop
fffff800`a6b6b23a cc              int     3
fffff800`a6b6b23b cc              int     3
fffff800`a6b6b23c cc              int     3
fffff800`a6b6b23d cc              int     3
fffff800`a6b6b23e cc              int     3
fffff800`a6b6b23f cc              int     3


And the command from your first post:

6: kd> .cxr 0xffffd00135eb3370
rax=0000000000020000 rbx=fffff800a6d7a1f0 rcx=0000000000001004
rdx=0000000000080004 rsi=000000003f0f4a01 rdi=0000000000020001
rip=fffff80017192b72 rsp=ffffd00135eb3d98 rbp=0000000000000401
 r8=ffffe0013f0f4a01  r9=ffffe0013f0f4a60 r10=ffffd0012ede6260
r11=ffffd00135eb3de8 r12=ffffd00135eb43a0 r13=0000000000080004
r14=0000000000000286 r15=0000000000001004
iopl=0         nv up di pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00000002
vtss+0x12b72:
fffff800`17192b72 c3              ret

 

Bernard
Black Belt
227 Views

Hi Etienne,

Thank you for running those commands unfortunately their output points to KeBugCheckExe routine which was executing on CPU(core) #6.

In order to dump assembly content of vtss driver please run these commands: ub fffff800`17192b72 and u fffff800`17192b72. These commands should helpfully show the code which probably caused BugCheck.

 

Bernard
Black Belt
227 Views

By looking at the call stack I suspect more CPUz utillity in causing that BugCheck. It seems that CPUz created and injected remote thread into address space of vtss driver.

Etienne_K_
Beginner
227 Views

6: kd> ub fffff800`17192b72
vtss+0x12b53:
fffff800`17192b53 488badd8000000  mov     rbp,qword ptr [rbp+0D8h]
fffff800`17192b5a 4881c4e8000000  add     rsp,0E8h
fffff800`17192b61 f644240801      test    byte ptr [rsp+8],1
fffff800`17192b66 7403            je      vtss+0x12b6b (fffff800`17192b6b)
fffff800`17192b68 0f01f8          swapgs
fffff800`17192b6b 48cf            iretq
fffff800`17192b6d 0f1f00          nop     dword ptr [rax]
fffff800`17192b70 cd00            int     0

 

6: kd> u fffff800`17192b72
vtss+0x12b72:
fffff800`17192b72 c3              ret
fffff800`17192b73 66666666660f1f840000000000 nop word ptr [rax+rax]
fffff800`17192b80 65488b042588010000 mov   rax,qword ptr gs:[188h]
fffff800`17192b89 488b90b8000000  mov     rdx,qword ptr [rax+0B8h]
fffff800`17192b90 488d8a78040000  lea     rcx,[rdx+478h]
fffff800`17192b97 48f7411800ffffff test    qword ptr [rcx+18h],0FFFFFFFFFFFFFF00h
fffff800`17192b9f 7503            jne     vtss+0x12ba4 (fffff800`17192ba4)
fffff800`17192ba1 33c0            xor     eax,eax

 

Ah ok, the problem is, I randomly also got a MACHINE_CODE_EXCEPTION bluescreen and the system crashed so hard that I couldnt get a memory dump. Afterwards I saw a vtss.sys error and I thought that maybe there would be something wrong with vtss which also led to the MACHINE_CODE_EXCEPTION.

 

I have since removed vtss from the workstation and I have not experienced any MACHINE_CODE_EXCEPTIONs

Bernard
Black Belt
227 Views

Is this MACHINE_CHECK_EXCEPTION or MACHINE_CODE_EXCEPTION type of BugCheck?

Etienne_K_
Beginner
227 Views

Sorry, it should have been MACHINE_CHECK_EXCEPTION.

Bernard
Black Belt
227 Views

MACHINE_CHECK_EXCEPTION is always related to critical hardware fault and it seems strange that vtss could cause that. Anyway I am glad that your issue has been solved by removing vtss.

I advise you to contact Intel Premium Support in order to get help.

Bernard
Black Belt
227 Views

Can you post  MACHINE_CHECK_EXCEPTION info as displayed by windbg?

Etienne_K_
Beginner
227 Views

Sadly not, because when I had MACHINE_CHECK_EXCEPTION Windows wasn't able to write a MEMDUMP :S :/

Bernard
Black Belt
227 Views

Do you have still that BugCheck even after removing vtss?

I still cannot understand how vtss can cause of course indirectly MACHINE_CHECK_EXCEPTION

Etienne_K_
Beginner
227 Views

I removed vtss 2 days ago, and so far I had no BugChecks :/

Bernard
Black Belt
227 Views

@Peter

Have you ever came across an issue where vtss caused MACHINE_CHECK_EXCEPTION BugCheck?

Peter_W_Intel
Employee
227 Views

I haven't heard this from others, before. Sorry.

You may use "amplxe-sepreg.exe -u" to unload drivers to avoid this, if this was caused by vtss and/or vtsspp drivers. Was it caused by resource limitation (memory)? Sometime rebooting system is required, then run "amplxe-sepreg.exe -i ".

Please try 2016 version, if you met this again - please send crash report by using:

>amplxe-feedback -create-bug-report <report archive>
>amplxe-feedback -send-crash-report=<report archive>