- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes. I extracted memory.dmp which was 946MB, near 1GB.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
And "additional options" window on same property page as well, please.
TIA!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 ---------
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did that , and still got BSOD. What info do you need.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@vasci
Can you upload full kernel dump to some external hosting website?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@iliyapolak
Can you explain how to get a "full kernel dump" and I will be happy to oblige.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
![](/skins/images/872293744008A34B36F8ABF94A46CC66/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page