This output makes sense to me. It says:
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for ntoskrnl.exe
With export symbols what you get back is going to look rather suspect.
Your symbol path:
Symbol search path is: c:\winnt\symbols
Would indicate that you are using your local machine’s debugging symbols
- these are usually used for debugging applications local to the system.
If your local machine (where you run WinDBG) happens to be a W2K system
(with no service packs) this should work right. My guess is that you
aren’t…
I’d suggest fixing your symbol search path to point to the public symbol
server (assuming an internet connect), or:
srv**http://msdl.microsoft.com/download/symbols
In later versions of the debugger this is done with the .symfix command.
Once you have set your symbol path, reload (“.reload”) and I suspect
your results will become vastly improved.
But the information IS there - you just can’t ignore symbol loading
errors for the OS.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Monday, August 22, 2005 12:09 PM
To: Kernel Debugging Interest List
Subject: Re: [windbg] debugging doubts
Thanks Don,
I added the /BREAK to boot.ini, now the debugger does halt the
machine. But the break point addresses seem weird.
Attached is the debuggers output, though I have set the break points
in atapi.sys and other files, the dubegger seems to halt in
ntoskrnl.sys. Also after the second break , the machine goes into a
loop and repeatedly keeps getting stuck at the same place.
kd> .reboot
Shutdown occurred…unloading all symbol tables.
Waiting to reconnect…
Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: c:\winnt\symbols
Executable search path is: c:\drv\src\objchk\i386
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for ntoskrnl.exe -
Windows 2000 Kernel Version 2195 UP Free x86 compatible
Kernel base = 0x804de000 PsLoadedModuleList = 0x805484c0
System Uptime: not available
The call to LoadLibrary(kdextx86) failed, Win32 error 1455
“The paging file is too small for this operation to complete.”
Please check your debugger configuration and/or network access.
The call to LoadLibrary(ext) failed, Win32 error 1455
“The paging file is too small for this operation to complete.”
Please check your debugger configuration and/or network access.
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
80530e64 cc int 3
kd> bl
0 eu 0001 (0001) (dump_atapi!driverentry)
1 eu 0001 (0001) (atapi!driverentry)
2 du 0001 (0001) (hiber_atapi!driverentry)
3 eu 0001 (0001) (diskperf!diskperfDeviceControl)
4 eu 0001 (0001) (diskperf!diskperfiocompletion)
5 eu 0001 (0001) (dump_atapi!AtapiCrashDumpDriverEntry)
6 eu 0001 (0001) (atapi!AtapiCrashDumpDriverEntry)
7 eu 0001 (0001) (dump_atapi!atapicrashdumpopen)
8 eu 0001 (0001) (atapi!atapicrashdumpopen)
9 eu 0001 (0001) (atapi!atapicrashdumpfinish)
10 eu 0001 (0001) (dump_atapi!atapicrashdumpfinish)
11 eu 0001 (0001) (dump_atapi!atapicrashdumpIdewrite)
12 eu 0001 (0001) (atapi!atapicrashdumpIdewrite)
13 eu 0001 (0001) (dump_atapi!DumpData)
14 eu 0001 (0001) (atapi!DumpData)
15 eu 0001 (0001) (dump_wmilib!wmicompleteRequest)
16 du 0001 (0001) (wmilib!wmicompleterequest)
17 du 0001 (0001) (wmilib!wmifireevent)
18 du 0001 (0001) (dump_wmilib!wmifireevent)
19 du 0001 (0001) (dump_wmilib!wmisystemcontrol)
20 du 0001 (0001) (wmilib!wmisystemcontrol)
kd> lm t n
start end module name
804de000 8066e900 nt ntoskrnl.exe Wed Dec 08 05:11:11 1999
(384D9B17)
No unloaded module list present
kd> g
*** ERROR: Symbol file could not be found. Defaulted to export
symbols for ntoskrnl.exe -
*** WARNING: symbols timestamp is wrong 0x4309b247 0x3e4abdee for
Diskperf.sys
*** ERROR: Module load completed but symbols could not be loaded for
atapi.sys
Breakpoint 1’s offset expression evaluation failed.
Check for invalid symbols or bad syntax.
WaitForEvent failed
nt!RtlUnwind+0x339:
80537082 8945fc mov [ebp-0x4],eax
kd> lm t c
start end module name
804de000 8066e900 nt Wed Dec 08 05:11:11 1999 (384D9B17)
0019B984
8066f000 80682d20 hal Wed Nov 03 06:44:22 1999 (381F8C6E)
0001705D
bfed2000 bfee6ae0 atapi Sun Dec 05 01:49:32 1999 (38497754)
0001DAA2
bfee7000 bff08220 dmio Wed Dec 01 01:17:49 1999 (384429E5)
0002FDC5
bff09000 bff250c0 ftdisk Tue Nov 23 01:06:23 1999 (38399B37)
0002B963
bff26000 bffd7ec0 OsiData Thu Jul 08 02:04:49 2004 (40EC5E69)
000BE562
bffd8000 bffffb40 ACPI Thu Nov 11 06:36:04 1999 (382A167C)
000295A0
eb400000 eb40e340 pci Thu Oct 28 04:41:08 1999 (3817868C)
00012CB0
eb410000 eb41b580 isapnp Sun Oct 03 01:30:35 1999 (37F66463)
00015782
eb680000 eb684280 cpthook Mon Dec 20 22:06:47 2004 (41C6FF9F)
000060DA
eb688000 eb68d4a0 PCIIDEX Thu Oct 28 04:32:19 1999 (3817847B)
0000BAFB
eb690000 eb697180 MountMgr Sat Oct 23 04:18:06 1999 (3810E9A6)
0000E831
eb810000 eb812a20 BOOTVID Thu Nov 04 06:54:33 1999 (3820E051)
0000D8A2
eb814000 eb816980 bootcfg Mon Dec 20 22:06:44 2004 (41C6FF9C)
0000ABA4
eb818000 eb81b100 Diskperf Mon Aug 22 16:38:55 2005 (4309B247)
00007B32
eb81c000 eb81eb80 PartMgr Fri Oct 15 06:29:16 1999 (38067C64)
0000742C
eb900000 eb901b80 dmload Wed Dec 01 01:17:49 1999 (384429E5)
00004FB6
eb9c8000 eb9c8f80 WMILIB Sun Sep 26 00:06:47 1999 (37ED163F)
00008BFD
eb9c9000 eb9c9aa0 pciide Thu Oct 28 04:32:19 1999 (3817847B)
00007C48
On 8/22/05, Don Burn wrote:
> You should be able to catch this. One approach to try is add a /BREAK
to
> the boot.ini line with the debugger entry. This will force a
breakpoint
> after the initial load of modules, but before these are run, see if
you
> breakpoint can be hit then.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Remove StopSpam from the email to reply
>
>
>
>
> “Developer” wrote in message
news:xxxxx@windbg…
> 1. I am trying to attach a break point to the driverentry routine of
> atapi.sys, windbg doesn’t seem to be able to catch it, is it because
> nt/2k starts sending info through serial port after atapi.sys is
> loaded?
>
> 2. Would a hardware debugger like line analyser help?
>
> 3. Even for other function calls inside atapi, which are called after
> windows has booted up, the break points don’t respond. Why so? Is
> there a restriction imposed on what all can be debugged? Or am I
> missing something.
>
>
> –
>
> - Developer
>
>
>
> —
> You are currently subscribed to windbg as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Developer
—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com