BSOD on Windows 7 using Amplifier 2015 Update 1 - Page 2

AndrewC · ‎11-10-2014

I am getting a 100% repeatable BSOD on Windows 7 running Amplifier 2015 Update 1 (build 380310), native code.

Advanced Hotspots ->Hotspots -> NO PROBLEM
Advanced Hotspots ->Hotspots , stacks and context switches ->BSOD after a few seconds.

Suggestions?

Robert_L_Intel1 · ‎11-11-2014

Assuming it really isn't a hardware issue, it's interesting that you have procexp64.exe in one case and WmiPrvSE.exe in the other two and it requires Intel® VTune Amplifier XE running with stacks and context switches.

Also, the IRQ level is 13 in the initial dump. I'm not sure how reliable that is, though, as the documentation says the important level is the one just before, and according to this chart, that is the profiler level for pre-win2k editions.

Maybe iliyapolak can make more sense of that. Perhaps you could upload the last dump as well?

At least it does seem possible it could still be a driver issue. I know that generally speaking with Intel® VTune Amplifier XE, if you have another profiler running at the same time, you will have problems.

http://blogs.msdn.com/b/doronh/archive/2010/02/02/what-is-irql.aspx

If I were to guess, and it's just a guess, I would say somehow, you have another profiler running or interfering intermittently. Either WMI or Process Explorer or both.

Marián__VooDooMan__M · ‎11-11-2014

@iliyapolak

oh, my err, after some examination, I found out that process explorer (yes, from sysinternals/technet/mark russinovich - kernel developer @MSFT) DOES use its own kernel driver.

I am attaching MEMORY.DMP (I don't have minidump any more), since I am not familiar with all commands in WinDbg, so iliyapolak might have better luck than me, in displaying ALL modules, not only kernel one's...

Since memory dump (approximately 1 GiB) might have sensitive information, I will attach it 7-zipped with password protection and I will send password to iliyapolak and all Intel staff incorporated so far in this thread via private message.

TIA iliyapolak!

AndrewC · ‎11-11-2014

No other profilers or process explorers running etc.

I do not have process explorer installed and it is not running. This computer is factory fresh with not much apart form Intel Composer 2015 and Visual Studio 2013 installed.

I reboot the machine after the BSDO, start Amplifier, start profiling, and BSOD again. 100% reproducible.

Marián__VooDooMan__M · ‎11-11-2014

Greetings,

I have posted here my memory dump of that BSOD (I don't have minidump any more), and I said that @iliyapolak was right, since after my investigation the process explorer does have a kernel driver.

The attachment of of memory dump was 7zipped with password, since it might contain sensitive informations, and I have sent password to @iliyapolak and all @intel staff incorporated so far in this thread, via private message. Please, use direct download link I sent in a private message.

Unfortunately, I have hit spam filter as a false-positive, FYI.

TIA!

Marián__VooDooMan__M · ‎11-11-2014

FYI, @Peter Wang (Intel) responded saying he'll pass dump to developers. Though, I have suspicion about the dump, which is nearly 1 GiB rich, and I have 16 GiB of RAM, so I don't know whether it is complete at all...

Peter_W_Intel · ‎11-12-2014

Yes. I extracted memory.dmp which was 946MB, near 1GB.

Marián__VooDooMan__M · ‎11-12-2014

@vasci_:Can you please tell the whole compiler options you used for the project, I have one guess. In project properties, go to "command line" and copy-paste "all options" window.

Marián__VooDooMan__M · ‎11-12-2014

And "additional options" window on same property page as well, please.

TIA!

Marián__VooDooMan__M · ‎11-12-2014

Gotcha!

I reproduced the crash when I re-added into compile option additional option: "/debug:inline-debug-info".

Though I don't know what this option has to do with profiling, since this option is only relevant to evaluate things, after application ends...

I will upload somewhere the new dump, and send link to Peter Wang (Intel).

for now, it is:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 101, {18, 0, ffffd00074780180, 7}

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

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

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

CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000018, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffffd00074780180, The PRCB address of the hung processor.
Arg4: 0000000000000007, 0.

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


BUGCHECK_STR:  CLOCK_WATCHDOG_TIMEOUT_8_PROC

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

PROCESS_NAME:  devenv.exe

CURRENT_IRQL:  d

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

STACK_TEXT:  
ffffd000`743a1c88 fffff801`9a16ef7f : 00000000`00000101 00000000`00000018 00000000`00000000 ffffd000`74780180 : nt!KeBugCheckEx
ffffd000`743a1c90 fffff801`9a03f165 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0xb8cf
ffffd000`743a1d20 fffff801`9a7a267f : 00000000`00000000 00000000`458822a7 ffffe000`d48003b0 00000000`00000000 : nt!KeClockInterruptNotify+0x785
ffffd000`743a1f40 fffff801`9a0e576a : ffffe000`d4800300 fffff801`9a10175b ffffd000`00000000 00000000`00000000 : hal!HalpTimerClockInterrupt+0x4f
ffffd000`743a1f70 fffff801`9a15462a : ffffe000`d4800300 00000000`490c97a5 fffff6d8`0114c618 00000000`00000000 : nt!KiCallInterruptServiceRoutine+0x8a
ffffd000`743a1fb0 fffff801`9a154a0f : 00000000`00000000 00000000`00000001 00000000`490a0e75 00000000`00000000 : nt!KiInterruptSubDispatchNoLockNoEtw+0xea
ffffd000`23a33240 fffff801`9a0a0bd4 : 00000000`00000000 00000000`00000000 00000000`00000001 ffffc000`41182c20 : nt!KiInterruptDispatchLBControl+0x11f
ffffd000`23a333d0 fffff801`9a0a0d4f : 00000000`00000000 00000000`00000002 00000000`80000003 00000000`00000000 : nt!KiIpiSendRequestEx+0x84
ffffd000`23a33420 fffff801`9a0a0b43 : 00000000`00000000 ffffd000`23a337d0 00000000`00000000 00000000`00000000 : nt!KxFlushEntireTb+0x8f
ffffd000`23a33470 fffff801`9a03ca20 : fffff6d8`0114c600 ffffd000`23a337d0 ffffd000`23a33780 00000000`00000000 : nt!KeFlushTb+0x167
ffffd000`23a33590 fffff801`9a04e9e8 : fffff6d8`0114c600 fffff6d8`0114c600 0000007c`00cd16d0 00000000`00000000 : nt!MiFlushTbList+0x300
ffffd000`23a336d0 fffff801`9a04e402 : 00000000`00000000 ffffe000`d4843ed8 00000000`00000000 ffffe000`db465f00 : nt!MiObtainSystemCacheView+0x2e4
ffffd000`23a33880 fffff801`9a04f0ba : 00000000`00000000 ffffe000`d4d19460 00000001`00000001 ffffd000`789ea830 : nt!MmMapViewInSystemCache+0x9e
ffffd000`23a339f0 fffff801`9a04baaf : 00000000`00000001 ffffe000`d5fd0df0 00000000`00000001 fffff800`00000001 : nt!CcGetVacbMiss+0x122
ffffd000`23a33a80 fffff801`9a3b55f6 : 00000000`00000001 00000000`00000000 ffffd000`23a33b90 ffffd000`23a33ba8 : nt!CcGetVirtualAddress+0x36f
ffffd000`23a33b20 fffff800`06b5344e : ffffc000`3a569000 ffffc000`51b4f428 00000000`00001000 ffffc000`51b4f420 : nt!CcMapData+0x72
ffffd000`23a33b90 fffff800`06b4fe34 : ffffe000`db8397b8 ffffc000`51b4f420 ffffc000`51b4f380 ffffc000`4f98d140 : Ntfs!ReadIndexBuffer+0xde
ffffd000`23a33c10 fffff800`06b58f56 : ffffe000`db8397b8 00000000`00000000 ffffe000`d471c180 ffffe000`00000000 : Ntfs!FindFirstIndexEntry+0x154
ffffd000`23a33ca0 fffff800`06b2d231 : ffffe000`db8397b8 ffffc000`51af3d82 ffffc000`51b4f380 ffffd000`2036c120 : Ntfs!NtfsFindIndexEntry+0x66
ffffd000`23a33d30 fffff800`06b4f57d : ffffe000`db8397b8 ffffe000`d4eb0300 ffffd000`2036c120 ffffe000`d5ca2001 : Ntfs!NtfsCommonCreate+0x811
ffffd000`23a33f50 fffff801`9a156af7 : ffffd000`2036c0f0 00000000`00000000 00000000`00000000 00000092`f66eb6a0 : Ntfs!NtfsCommonCreateCallout+0x1d
ffffd000`23a33f80 fffff801`9a156abd : 00000000`00000000 00000000`00000000 00000000`00000002 fffff801`9a0c0153 : nt!KxSwitchKernelStackCallout+0x27
ffffd000`2036bf60 fffff801`9a0c0153 : 00000000`00000006 00000000`00000000 00000000`00000006 00000000`00000000 : nt!KiSwitchKernelStackContinue
ffffd000`2036bf80 fffff800`06b4de5f : fffff800`06b4f560 ffffd000`2036c0f0 ffffe000`db839700 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0x2f3
ffffd000`2036c070 fffff800`0693acf8 : ffffe000`d471c030 ffffe000`d4eb0300 00000000`00000000 00000000`00000270 : Ntfs!NtfsFsdCreate+0x1cf
ffffd000`2036c260 fffff800`06963341 : ffffe000`d7422010 ffffe000`d4eb0300 ffffe000`d69ff4f0 ffffd000`2036c338 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x258
ffffd000`2036c300 fffff801`9a3cabae : 00000000`00000000 00000000`00000045 00000000`00000000 ffffd000`00000040 : fltmgr!FltpCreate+0x342
ffffd000`2036c3b0 fffff801`9a3c33fa : ffffc000`3a012b28 ffffc000`3a012b28 ffffc000`3a095d90 ffffe000`d69732d0 : nt!IopParseDevice+0x6be
ffffd000`2036c5c0 fffff801`9a3c20d3 : 00000000`00000000 ffffd000`2036c7b8 ffffe000`00000040 ffffe000`d482bc60 : nt!ObpLookupObjectName+0x6ca
ffffd000`2036c740 fffff801`9a4a20ff : ffffe000`00000001 00000000`063ae7e8 00000000`063afdb0 00000000`063af0c0 : nt!ObOpenObjectByName+0x1e3
ffffd000`2036c870 fffff801`9a15e9b3 : 00000000`31f6348b 00000000`00000d3c ffffe000`d5ca2080 00000000`77897ad8 : nt!NtQueryFullAttributesFile+0x147
ffffd000`2036cb00 00007ffe`ab57290a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`063ae7a8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`ab57290a


STACK_COMMAND:  kb

SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

IMAGE_VERSION:  

FAILURE_BUCKET_ID:  CLOCK_WATCHDOG_TIMEOUT_8_PROC_ANALYSIS_INCONCLUSIVE

BUCKET_ID:  CLOCK_WATCHDOG_TIMEOUT_8_PROC_ANALYSIS_INCONCLUSIVE

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:clock_watchdog_timeout_8_proc_analysis_inconclusive

FAILURE_ID_HASH:  {f60c102e-9b2c-017b-9309-e4af1999e360}

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

Vitaly_S_Intel · ‎11-12-2014

Marian, are you saying that if compiler option is not specified for your application, there is no BSOD, but if option is used, then collecting with advanced hotspots + stacks leads to BSOD?

Marián__VooDooMan__M · ‎11-12-2014

Vitaly Slobodskoy (Intel) wrote:

Marian, are you saying that if compiler option is not specified for your application, there is no BSOD, but if option is used, then collecting with advanced hotspots + stacks leads to BSOD?

Yes, but it may be also option in VTune "analyze system-wide" turned on. I will send you link to dump and link to 7zpipped configuration folder for crashed analysis/BSOD as a private message.

Marián__VooDooMan__M · ‎11-12-2014

I've sent it now. It looks like vtss.sys driver corrupts foreigner's memory, and pseudo-random process will pay for it, because kernel gets hung and watchdog sends time-out signal. But I am not so competent to say this.

Marián__VooDooMan__M · ‎11-12-2014

Sorry, I was too early. Now I did analysis on same image/binaries with "analyse system-wide" turned off, and analysis was successful.

I should google what this options is actually supposed to do.

It looks like it corrupts some kernel memory, or maybe reconfigures HW timers/watchdog, and Windows don't like it, I'm not sure.

Bernard · ‎11-12-2014

vasci_ wrote:

0: kd> !prcb 1
Cannot get PRCB address
0: kd> !prcb fffff80038a518
Cannot get PRCB address

You are probably running !prcb command on minidump file hence the windbg output.

Bernard · ‎11-12-2014

Marián "VooDooMan" Meravý wrote:

Gotcha!

I reproduced the crash when I re-added into compile option additional option: "/debug:inline-debug-info".

Though I don't know what this option has to do with profiling, since this option is only relevant to evaluate things, after application ends...

I will upload somewhere the new dump, and send link to Peter Wang (Intel).

for now, it is:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 101, {18, 0, ffffd00074780180, 7}

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

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

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

CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000018, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffffd00074780180, The PRCB address of the hung processor.
Arg4: 0000000000000007, 0.

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


BUGCHECK_STR:  CLOCK_WATCHDOG_TIMEOUT_8_PROC

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

PROCESS_NAME:  devenv.exe

CURRENT_IRQL:  d

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

STACK_TEXT:  
ffffd000`743a1c88 fffff801`9a16ef7f : 00000000`00000101 00000000`00000018 00000000`00000000 ffffd000`74780180 : nt!KeBugCheckEx
ffffd000`743a1c90 fffff801`9a03f165 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0xb8cf
ffffd000`743a1d20 fffff801`9a7a267f : 00000000`00000000 00000000`458822a7 ffffe000`d48003b0 00000000`00000000 : nt!KeClockInterruptNotify+0x785
ffffd000`743a1f40 fffff801`9a0e576a : ffffe000`d4800300 fffff801`9a10175b ffffd000`00000000 00000000`00000000 : hal!HalpTimerClockInterrupt+0x4f
ffffd000`743a1f70 fffff801`9a15462a : ffffe000`d4800300 00000000`490c97a5 fffff6d8`0114c618 00000000`00000000 : nt!KiCallInterruptServiceRoutine+0x8a
ffffd000`743a1fb0 fffff801`9a154a0f : 00000000`00000000 00000000`00000001 00000000`490a0e75 00000000`00000000 : nt!KiInterruptSubDispatchNoLockNoEtw+0xea
ffffd000`23a33240 fffff801`9a0a0bd4 : 00000000`00000000 00000000`00000000 00000000`00000001 ffffc000`41182c20 : nt!KiInterruptDispatchLBControl+0x11f
ffffd000`23a333d0 fffff801`9a0a0d4f : 00000000`00000000 00000000`00000002 00000000`80000003 00000000`00000000 : nt!KiIpiSendRequestEx+0x84
ffffd000`23a33420 fffff801`9a0a0b43 : 00000000`00000000 ffffd000`23a337d0 00000000`00000000 00000000`00000000 : nt!KxFlushEntireTb+0x8f
ffffd000`23a33470 fffff801`9a03ca20 : fffff6d8`0114c600 ffffd000`23a337d0 ffffd000`23a33780 00000000`00000000 : nt!KeFlushTb+0x167
ffffd000`23a33590 fffff801`9a04e9e8 : fffff6d8`0114c600 fffff6d8`0114c600 0000007c`00cd16d0 00000000`00000000 : nt!MiFlushTbList+0x300
ffffd000`23a336d0 fffff801`9a04e402 : 00000000`00000000 ffffe000`d4843ed8 00000000`00000000 ffffe000`db465f00 : nt!MiObtainSystemCacheView+0x2e4
ffffd000`23a33880 fffff801`9a04f0ba : 00000000`00000000 ffffe000`d4d19460 00000001`00000001 ffffd000`789ea830 : nt!MmMapViewInSystemCache+0x9e
ffffd000`23a339f0 fffff801`9a04baaf : 00000000`00000001 ffffe000`d5fd0df0 00000000`00000001 fffff800`00000001 : nt!CcGetVacbMiss+0x122
ffffd000`23a33a80 fffff801`9a3b55f6 : 00000000`00000001 00000000`00000000 ffffd000`23a33b90 ffffd000`23a33ba8 : nt!CcGetVirtualAddress+0x36f
ffffd000`23a33b20 fffff800`06b5344e : ffffc000`3a569000 ffffc000`51b4f428 00000000`00001000 ffffc000`51b4f420 : nt!CcMapData+0x72
ffffd000`23a33b90 fffff800`06b4fe34 : ffffe000`db8397b8 ffffc000`51b4f420 ffffc000`51b4f380 ffffc000`4f98d140 : Ntfs!ReadIndexBuffer+0xde
ffffd000`23a33c10 fffff800`06b58f56 : ffffe000`db8397b8 00000000`00000000 ffffe000`d471c180 ffffe000`00000000 : Ntfs!FindFirstIndexEntry+0x154
ffffd000`23a33ca0 fffff800`06b2d231 : ffffe000`db8397b8 ffffc000`51af3d82 ffffc000`51b4f380 ffffd000`2036c120 : Ntfs!NtfsFindIndexEntry+0x66
ffffd000`23a33d30 fffff800`06b4f57d : ffffe000`db8397b8 ffffe000`d4eb0300 ffffd000`2036c120 ffffe000`d5ca2001 : Ntfs!NtfsCommonCreate+0x811
ffffd000`23a33f50 fffff801`9a156af7 : ffffd000`2036c0f0 00000000`00000000 00000000`00000000 00000092`f66eb6a0 : Ntfs!NtfsCommonCreateCallout+0x1d
ffffd000`23a33f80 fffff801`9a156abd : 00000000`00000000 00000000`00000000 00000000`00000002 fffff801`9a0c0153 : nt!KxSwitchKernelStackCallout+0x27
ffffd000`2036bf60 fffff801`9a0c0153 : 00000000`00000006 00000000`00000000 00000000`00000006 00000000`00000000 : nt!KiSwitchKernelStackContinue
ffffd000`2036bf80 fffff800`06b4de5f : fffff800`06b4f560 ffffd000`2036c0f0 ffffe000`db839700 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0x2f3
ffffd000`2036c070 fffff800`0693acf8 : ffffe000`d471c030 ffffe000`d4eb0300 00000000`00000000 00000000`00000270 : Ntfs!NtfsFsdCreate+0x1cf
ffffd000`2036c260 fffff800`06963341 : ffffe000`d7422010 ffffe000`d4eb0300 ffffe000`d69ff4f0 ffffd000`2036c338 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x258
ffffd000`2036c300 fffff801`9a3cabae : 00000000`00000000 00000000`00000045 00000000`00000000 ffffd000`00000040 : fltmgr!FltpCreate+0x342
ffffd000`2036c3b0 fffff801`9a3c33fa : ffffc000`3a012b28 ffffc000`3a012b28 ffffc000`3a095d90 ffffe000`d69732d0 : nt!IopParseDevice+0x6be
ffffd000`2036c5c0 fffff801`9a3c20d3 : 00000000`00000000 ffffd000`2036c7b8 ffffe000`00000040 ffffe000`d482bc60 : nt!ObpLookupObjectName+0x6ca
ffffd000`2036c740 fffff801`9a4a20ff : ffffe000`00000001 00000000`063ae7e8 00000000`063afdb0 00000000`063af0c0 : nt!ObOpenObjectByName+0x1e3
ffffd000`2036c870 fffff801`9a15e9b3 : 00000000`31f6348b 00000000`00000d3c ffffe000`d5ca2080 00000000`77897ad8 : nt!NtQueryFullAttributesFile+0x147
ffffd000`2036cb00 00007ffe`ab57290a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`063ae7a8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`ab57290a


STACK_COMMAND:  kb

SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

IMAGE_VERSION:  

FAILURE_BUCKET_ID:  CLOCK_WATCHDOG_TIMEOUT_8_PROC_ANALYSIS_INCONCLUSIVE

BUCKET_ID:  CLOCK_WATCHDOG_TIMEOUT_8_PROC_ANALYSIS_INCONCLUSIVE

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:clock_watchdog_timeout_8_proc_analysis_inconclusive

FAILURE_ID_HASH:  {f60c102e-9b2c-017b-9309-e4af1999e360}

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

As I cannot download full kernel dump of the BSOD I will ask you to run !prcb command when full kernel dump is opened by windbg. PCRB of following cores: CPU0 , CPU1,CPU3 need to be investigated in order to find the hung core(CPU). PCRB command can display currently executed thread at the time of BSOD so the next step will be context setting to this thread and dumping its kernel mode stack. I am not sure if devenv.exe caused directly that crash I think that this is so called process context.

Bernard · ‎11-12-2014

Marián "VooDooMan" Meravý wrote:

I've sent it now. It looks like vtss.sys driver corrupts foreigner's memory, and pseudo-random process will pay for it, because kernel gets hung and watchdog sends time-out signal. But I am not so competent to say this.

I think that here could be hidden a culprit or at least some clue which could point to involvement of VTune itself.

00000000`063ae7a8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007ffe`ab57290a

Stanislav_B_Intel1 · ‎11-13-2014

Hello,

Would anyone who has 100% reproducible BSOD please help me narrow down the problem by invoking vtss.sys driver without call stacks?

For that, you may need to set up Advanced Hotspots + call stacks and context switches; then create a custom analysis by right-clicking on the Advanced Hotspots, then selecting "Copy from current" option, and finally un-checking "Collect stacks" box in the Custom Analysis dialog (please see a screenshot attached for reference).

Will very much appreciate your help, as problems connected with hang-ups or memory corruption are very hard to debug in the kernel space.

Thanks,

Stas

AndrewC · ‎11-13-2014

I did that , and still got BSOD. What info do you need.

Bernard · ‎11-14-2014

@vasci

Can you upload full kernel dump to some external hosting website?

AndrewC · ‎11-14-2014

@iliyapolak

Can you explain how to get a "full kernel dump" and I will be happy to oblige.

Bernard · ‎11-14-2014

Full kernel dump should be generated by Windows when BSOD occures. Usually it is placed in C:\Windows directory and it is named Memory.dmp