Windows 7 BSOD - not sure if analyzing memory.dmp correctly

[AS147]

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 Link Removed

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]http://msdl.microsoft.com/download/symbols[/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                                    *
*                                                                             *
*******************************************************************************
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
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.
Arguments:
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 
CURRENT_IRQL:  2
FAULTING_IP: 
hcw89+5ae9e
9c28fe9e 8b01            mov     eax,dword ptr [ecx]
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:  0xD1
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
hcw89+0x5ae9e:
9c28fe9e 8b01            mov     eax,dword ptr [ecx]  ds:0023:00000830=????????
Resetting default scope
LAST_CONTROL_TRANSFER:  from 9c28fe9e to 82e7b65b
STACK_TEXT:  
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

STACK_COMMAND:  kb
FOLLOWUP_IP: 
hcw89+5ae9e
9c28fe9e 8b01            mov     eax,dword ptr [ecx]
SYMBOL_STACK_INDEX:  1
SYMBOL_NAME:  hcw89+5ae9e
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: hcw89
IMAGE_NAME:  hcw89.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  4c125992
FAILURE_BUCKET_ID:  0xD1_hcw89+5ae9e
BUCKET_ID:  0xD1_hcw89+5ae9e
Followup: MachineOwner
---------

 

[usasma]

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: Link Removed
Here's a shortcut to that driver's page: Link Removed

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.

 

[AS147]

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

 

[usasma]

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.