BSOD - not sure if analyzing memory.dmp correctly

Discussion in 'Windows 7 Blue Screen of Death (BSOD)' started by AS147, Aug 11, 2012.

  1. AS147

    AS147 New Member

    Aug 11, 2012
    Likes Received:
    Hi folks, newbie here and I have read the useful beginners guide to BSOD's on this forum.

    I followed the msdn article to debug my memory.dmp file Troubleshoot a Windows bluescreen, a.k.a bugcheck, a.k.a blue screen of death - The NDIS blog - Site Home - MSDN Blogs

    1. downloaded the correct MS debugger and the x86 symbols
    2. loaded the memory dump in the debugger
    3. loaded the symbols for the OS
    4. Issued the command in the debugger comman line window "!analyze -v"

    Unfortunately I got the following and wondered whether the symbols error can be ignored and if some clue as to the reason for the crash can be seen. Here is my extract from the debug tool. I am running Windows 7 home premium with SP1
    Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
    Copyright (c) Microsoft Corporation. All rights reserved.
    Loading Dump File [C:\Windows\MEMORY.DMP]
    Kernel Summary Dump File: Only kernel address space is available
    Symbol search path is: srv*C:\Symbols*[URL][/URL]
    Executable search path is: 
    Windows 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x86 compatible
    Product: WinNt, suite: TerminalServer SingleUserTS Personal
    Built by: 7601.17803.x86fre.win7sp1_gdr.120330-1504
    Machine Name:
    Kernel base = 0x82e3a000 PsLoadedModuleList = 0x82f834d0
    Debug session time: Sat Aug 11 23:14:38.347 2012 (UTC + 10:00)
    System Uptime: 0 days 10:50:21.141
    Loading Kernel Symbols
    Loading User Symbols
    Loading unloaded module list
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    Use !analyze -v to get detailed debugging information.
    BugCheck D1, {830, 2, 0, 9c28fe9e}
    *** ERROR: Module load completed but symbols could not be loaded for hcw89.sys
    Probably caused by : hcw89.sys ( hcw89+5ae9e )
    Followup: MachineOwner
    2: kd> !analyze -v
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    An attempt was made to access a pageable (or completely invalid) address at an
    interrupt request level (IRQL) that is too high.  This is usually
    caused by drivers using improper addresses.
    If kernel debugger is available get stack backtrace.
    Arg1: 00000830, memory referenced
    Arg2: 00000002, IRQL
    Arg3: 00000000, value 0 = read operation, 1 = write operation
    Arg4: 9c28fe9e, address which referenced memory
    Debugging Details:
    READ_ADDRESS:  00000830 
    9c28fe9e 8b01            mov     eax,dword ptr [ecx]
    PROCESS_NAME:  System
    TRAP_FRAME:  8df1cbe4 -- (.trap 0xffffffff8df1cbe4)
    ErrCode = 00000000
    eax=016002fe ebx=9c2f4cca ecx=00000830 edx=00000000 esi=8888bd08 edi=9c2f4c96
    eip=9c28fe9e esp=8df1cc58 ebp=8df1cc68 iopl=0         nv up ei pl nz na po nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010202
    9c28fe9e 8b01            mov     eax,dword ptr [ecx]  ds:0023:00000830=????????
    Resetting default scope
    LAST_CONTROL_TRANSFER:  from 9c28fe9e to 82e7b65b
    8df1cbe4 9c28fe9e badb0d00 00000000 86db2248 nt!KiTrap0E+0x2cf
    WARNING: Stack unwind information not available. Following frames may be wrong.
    8df1cc68 9c23d74f 00000000 00000000 8df1ccd4 hcw89+0x5ae9e
    8df1cc78 82eb21b5 870225e4 87328728 87328768 hcw89+0x874f
    8df1ccd4 82eb2018 8df00120 8df05800 00000000 nt!KiExecuteAllDpcs+0xf9
    8df1cd20 82eb1e38 00000000 0000000e 00000000 nt!KiRetireDpcList+0xd5
    8df1cd24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38
    9c28fe9e 8b01            mov     eax,dword ptr [ecx]
    SYMBOL_NAME:  hcw89+5ae9e
    FOLLOWUP_NAME:  MachineOwner
    MODULE_NAME: hcw89
    IMAGE_NAME:  hcw89.sys
    FAILURE_BUCKET_ID:  0xD1_hcw89+5ae9e
    BUCKET_ID:  0xD1_hcw89+5ae9e
    Followup: MachineOwner
    #1 AS147, Aug 11, 2012
    Last edited by a moderator: Aug 12, 2012
  2. usasma

    usasma Fantastic Member
    Microsoft Community Contributor

    Mar 22, 2010
    Likes Received:
    Fantastic work!

    The symbol errors are to be expected when they involve a driver that's not from Microsoft. The Symbol Server that you connect to is Microsoft's, so it doesn't have the private symbol files for other manufacturers (in this case Hauppage)

    You can look up the driver that's blamed in my Driver Reference Table (DRT) here: Driver Reference Table (DRT)
    Here's a shortcut to that driver's page: Driver Reference Table - hcw89.sys

    The easiest thing at this point is to uninstal l the Hauppage drivers/software, then download a fresh copy from their website and install it (as I recall, there can be up to 5 different programs involved).

    If that doesn't stop the BSOD's, post back and we'll show you some more stuff to do with the debugger and with other reports.
  3. AS147

    AS147 New Member

    Aug 11, 2012
    Likes Received:
    Thanks very much John. The BSOD happened a few times last year and then stopped. Then for the first time this year it happened again a few days ago. At least I know what to do in the future but as recommended I have updated the Huappauge drivers and will monitor to see how things progress.

    You are the first person I have found that identified the need to point to a different url for the debugger. It never stated that in the msdn article I referenced. I will keep this posting for future reference.

    Thanks once again
  4. usasma

    usasma Fantastic Member
    Microsoft Community Contributor

    Mar 22, 2010
    Likes Received:
    Private symbols (in general) belong to 3rd party drivers. Public symbols are mostly Windows drivers (I'm unsure if they include their own hardware drivers). There may be some public symbol servers for 3rd party drivers out on the web - but I've never looked for them.

    There's 2 primary problems with private symbols (IMO):
    - they're private (most companies don't want to release them to users)
    - they're usually only available from the company that developed that driver - so you'll need many, many different symbol server URL's in order to cover all the different company's drivers that are on your system

    I developed the Driver Reference Table (DRT) in order to get around this problem (most BSOD's are caused by 3rd party drivers)
    When a driver shows up as not having a symbol available, it's a clue to me that something in the debugger needs that symbol - so it's more likely that that driver could be associated with the problem (but this isn't a 100% certain assumption).

    We look at these (and other 3rd party drivers) in order to figure out where the problem could be - then the DRT is used to point you to the software needed to update that particular driver. It's sorta like the "translator" that translates hcw89.sys into the name and company of the device and a link to that company's driver download pages.

    In your case, even without the symbols the debugger pointed to the Hauppage driver as being at fault.
    Just remember that in the level of debugging that we do - we work on finding clues that point to likely problems - nothing is 100% certain until the problem is actually fixed.

    The experts for WinDbg are generally developers. They're deeply involved in figuring out which line of code is causing problems - so they can go in and fix the program.

    In our case, we can't fix these problems with code - so our solution is to remove them and replace them with a known good copy.
    This means that we don't need to perform the in-depth analysis that developers do. Our skills (the one's who help users with BSOD's) are mainly based on experience - along with some knowledge of Windows Internals and some knowledge of debugging.
    #4 usasma, Aug 13, 2012
    Last edited: Aug 13, 2012

Share This Page