Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Defrag Tools: #15 - WinDbg - Bugchecks (BSOD)

Download

Right click “Save as…”

In this episode of Defrag Tools, Chad Beeder and Larry Larsen discuss analyzing kernel mode bugchecks (colloquially known as Blue Screens of Death) using WinDbg from the Debugging Tools For Windows.

We use these commands:

  • !analyze -v
  • .hh
  • .trap
  • !pte
  • !process
  • !thread
  • .formats
  • .process
  • .thread
  • k
  • ~
  • .reload

Make sure you watch Defrag Tools Episode #1 for instructions on how to get the Debugging Tools for Windows and how to set the required environment variables for symbols and source code resolution.

Resources:

Debugging Tools for Windows

How to generate a kernel or a complete memory dump file in Windows Server 2008 and Windows Server 2008 R2

Windows Internals book tools (including NotMyFault)

Timeline:

[00:50] - What is a bugcheck (blue screen)?
[03:23] - Different types of memory dump files (complete, kernel-only, mini)
[05:16] - Windows Error Reporting
[07:17] - Configuring your system for a memory dump
[07:54] - Enabling "Complete memory dump" option on Windows 7 and Server 2008 R2; see KB 969028
[10:45] - Looking at a 32-bit memory dump created by NotMyFault
[12:04] - Symbol path
[13:21] - Step 1 is always: !analyze -v
[15:40] - Looking up bug check descriptions - Windows Debugger Help (.hh)
[19:45] - Looking at the trap frame (.trap)
[20:18] - Why did a memory access fail? (Using !pte command to look at virtual memory mappings)
[22:15] - What is a trap frame? (64-bit systems do not store all registers in trap frames; see blog post here)
[26:50] - Showing all running processes with !process 0 0
[28:48] - View more details on a specific process with !process
[31:43] - Converting between numerical formats with .formats
[32:55] - Switching the debugger into a process or thread context: use .process or .thread
[35:10] - Switching between CPUs (~ command)
[38:13] - Next week: Driver Verifier

Tag:

Follow the Discussion

  • MagicAndre1981Magic​Andre1981 xperf addicted

    [03:23] - Different types of memory dump files (complete, kernel-only, mini)

    [07:17] - Configuring your system for a memory dump

    please also explain what the new "Automatic dump" option under Windows 8 does in the next episodes

    Win7 got a hotfix to create dumps without page file:

    A hotfix is available that enables a Windows 7-based computer to create a memory dump file without a page file
    http://support.microsoft.com/kb/2716542/en-us

    But for me the fix doesn't work.

    [15:40] - Looking up bug check descriptions

    I'm using this site:

    http://msdn.microsoft.com/en-us/library/hh994433%28v=vs.85%29.aspx

    Btw, there are still some bugchecks missing which are only listed in the bugcodes.h from the WDK. Will those one be published? If not, why?

     

  • Andrew Richardswindev Andrew Richards

    Gangster Chad serves you up BSOD lyrics. Wink

  • d_blkdcrearer d_blk

    Chad I see in the windows internal 6th edition that the virtual address space for 32-bit x86 is 0x00000000 - 0x7fffffff for user process and 0x80000000 - 0xffffffff for protected operating system memory.

    What are the values for a 64-bit x64 system?

    I agree with Andrew that was an awesome demo. Can't wait for more!!!

  • @MagicAndre1981: This episode was taped before Windows 8 official release. We may talk more about the Windows 8 "Automatic memory dump" setting in the future, but for now there is a pretty good blog post from the Windows Server Core Team which goes into detail about this feature.

    I haven't tried the KB 2716542 hotfix to allow memory dumps without a page file, but based on what I can see about it, you may also need to set "DedicatedDumpFile" in the registry to get it to work. (See KB 969028 for details on DedicatedDumpFile.) I would not recommend running without a page file in most cases, however. This is really intended for specialized systems (i.e. embedded systems) which run a limited set of applications with known memory requirements.

    I'm not sure about the bugchecks which are listed in bugcodes.h but not documented. I'd guess that they aren't widely used (or deprecated in current Windows versions), or they may only be used in checked or internal debug builds of Windows. In any event, it's highly unlikely you'd see them in real-world scenarios.

  • @dcrearer: I don't have a 6th Edition Windows Internals handy at the moment, but in my 5th Edition copy, there is a chart of the x64 address space layout, so hopefully it's still there!

    On x64, user process address space is 0x0000000000000000 - 0x000007FFFFFEFFFF (8TB minus 64KB).
    System space is from 0xFFFF080000000000 - 0xFFFFFFFFFFFFFFFF.

    We will do more episodes on debugging. Thanks for watching!

  • MagicAndre1981Magic​Andre1981 xperf addicted

    ChadBeeder wrote

    @MagicAndre1981: This episode was taped before Windows 8 official release. We may talk more about the Windows 8 "Automatic memory dump" setting in the future, but for now there is a pretty good blog post from the Windows Server Core Team which goes into detail about this feature.

    I haven't tried the KB 2716542 hotfix to allow memory dumps without a page file, but based on what I can see about it, you may also need to set "DedicatedDumpFile" in the registry to get it to work. (See KB 969028 for details on DedicatedDumpFile.) I would not recommend running without a page file in most cases, however. This is really intended for specialized systems (i.e. embedded systems) which run a limited set of applications with known memory requirements.

    I'm not sure about the bugchecks which are listed in bugcodes.h but not documented. I'd guess that they aren't widely used (or deprecated in current Windows versions), or they may only be used in checked or internal debug builds of Windows. In any event, it's highly unlikely you'd see them in real-world scenarios.

    I've already read the blog post, but other users not. So you should also explain it here.

    I must say I've reduced the size of the page file to 2048 - 4096 MB. Does the fix only work for Systems without a pagefile or does it also work for smaller page files? I don't want to waste 16GB of space on my SSD.

    the bugchecks that are missing are mostly ones which were added since Vista. From 0x13x and 0x14x there are a lot of undocumented bugchecks.

  • @MagicAndre1981: Did you try adding the DedicatedDumpFile setting?

    Yeah, it looks like the people in charge of maintaining the debugger help file haven't gotten around to documenting all those newer bugchecks. Bugcodes.h contains the most definitive list of codes used by Windows components. Of course, third-party drivers are free to use any bugcheck code they want.

  • MagicAndre1981Magic​Andre1981 xperf addicted

    ChadBeeder wrote

    @MagicAndre1981: Did you try adding the DedicatedDumpFile setting?

    yes, but this makes it even worse. Now the Dedicated dump is 16GB and I have still my normal pagefile. So this is no option.

    ChadBeeder wrote

    Yeah, it looks like the people in charge of maintaining the debugger help file haven't gotten around to documenting all those newer bugchecks. Bugcodes.h contains the most definitive list of codes used by Windows components.

    will they ever add those missing bugchecks to the documentation? Have you asked them?

  • @MagicAndre1981: Yes, I've asked. A few of the newer bugchecks have been added to the documentation, but it's not clear every single one needs to be added. A lot of these bugchecks are rarely, if ever, seen in the wild. If there are specific ones that need to be documented, we can ask for them.

  • MagicAndre1981Magic​Andre1981 xperf addicted

    @ChadBeeder

    I've seen some of them and the only useful information came from !analyze -show BUGCHECKNUMBER in WinDbg. The next confusing thing is that the new bugcodes.h no longer contains the MessageText with some information. What I want to know is thebugcheck VHD_BOOT_HOST_VOLUME_NOT_ENOUGH_SPACE (136). Can I see from the parameters, how much free space I need to boot the VHD?

    Can you also ask the Debugger Team 2 things?

    1.) Sometimes I have the issue that the text is displayed twice:

    this happens randomly after stopping a former debug session with SHIFT+F5.

    2.) the new Dbghelper DLLs are slow to process the PDBs. It takes much longer to load them with the new DLLs from Win8 SDK. replacing them with old ones fixes the slow loading. I noticed this most when using xperfview.

  • Andrew Richardswindev Andrew Richards

    @MagicAndre1981:

    #1 - This happens when a Event or Output Callback from an extension is not behaving. Try loading with Windbg -WX to see if it goes away.

    #2 - This might relate to the new inline support. Can you collect a xPerf of the two scenarios?

  • MagicAndre1981Magic​Andre1981 xperf addicted

    #1 it happens very randomly, so I have no idea if -WX fixes it. And the dumps are different ones, so I never use the same WS again.

    #2 which flags should I capture? Here is also an user who has this issue:

    http://randomascii.wordpress.com/2012/10/04/xperf-symbol-loading-pitfalls/

Remove this comment

Remove this thread

close

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.