- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you run .cxr 0xffffd00135eb3370 command in order to display exception context?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this MACHINE_CHECK_EXCEPTION or MACHINE_CODE_EXCEPTION type of BugCheck?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry, it should have been MACHINE_CHECK_EXCEPTION.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you post MACHINE_CHECK_EXCEPTION info as displayed by windbg?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sadly not, because when I had MACHINE_CHECK_EXCEPTION Windows wasn't able to write a MEMDUMP :S :/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have still that BugCheck even after removing vtss?
I still cannot understand how vtss can cause of course indirectly MACHINE_CHECK_EXCEPTION
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I removed vtss 2 days ago, and so far I had no BugChecks :/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Peter
Have you ever came across an issue where vtss caused MACHINE_CHECK_EXCEPTION BugCheck?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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>

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page