I can boot the machine without any problem, however when I connect the
debugger I get
Microsoft (R) Windows Debugger Version 6.4.0007.2 http:
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \.\com1
Waiting to reconnect…
Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: SRVc:\symserver
http://msdl.microsoft.com/download/symbols;C:\DRV\symbols
Executable search path is:
Windows 2000 Kernel Version 2195 UP Free x86 compatible
Kernel base = 0x804de000 PsLoadedModuleList = 0x805484c0
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
80530e64 cc int 3
*** Fatal System Error: 0x0000000a
(0x00000000,0x00000002,0x00000001,0x8050B5B4)
I added a /BREAK in Boot.INI. It just won’t let me debug!
–
- Developer</http:>
My experience with this same trap is a problem with the symbols. I saw this in 6.4/5 when my symbols are out of sync with my driver and the 6.4+ debugger cannot resolve the symbols with the breakpoint. Instead of ignoring the BP like older versions do, it throws a fit and forces a breakpoint you cannot resolve. Try doing a “bc*” in the command line to clear all your breakpoints, or boot to safe mode and get your SYS and PDB files in sync. If the trap happens in Safe Mode, and I have seen it happen, then boot to the repair console and disable your driver, and sync SYS/PDB. You might also try killing the 6.4 WinDbg session, and starting 6.3 or older, hopefully the older behavior will then be invoked and the BP ignored.
The point is, you have to resolve the symbology problem, and versions 6.4+ do not allow you to do that, in fact they simply get in the way, so you have to resort to other means. At least that has been my experience with 6.4+.
–
The personal opinion of
Gary G. Little
“Developer” wrote in message news:xxxxx@windbg…
I can boot the machine without any problem, however when I connect the debugger I get
Microsoft (R) Windows Debugger Version 6.4.0007.2
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \.\com1
Waiting to reconnect…
Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
Kernel Debugger connection established.
Symbol search path is: SRVc:\symserverhttp://msdl.microsoft.com/download/symbols;C:\DRV\symbols
Executable search path is:
Windows 2000 Kernel Version 2195 UP Free x86 compatible
Kernel base = 0x804de000 PsLoadedModuleList = 0x805484c0
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
80530e64 cc int 3
*** Fatal System Error: 0x0000000a
(0x00000000,0x00000002,0x00000001,0x8050B5B4)
I added a /BREAK in Boot.INI. It just won’t let me debug!
–
- Developer
alas,
the debugger doesn’t drop down to the comand prompt. It just keeps
displaying the same error code and then reboots the debugee. Even killing
Windbg and restarting it again doesn’t help. I am not running any of my
drivers in the system yet, yes it has some drivers for which I don’t have
any symbols, for example the third party display drivers. I will try
removing them and try.
On 8/30/05, Gary G. Little wrote:
>
> My experience with this same trap is a problem with the symbols. I saw
> this in 6.4/5 when my symbols are out of sync with my driver and the 6.4+debugger cannot resolve the symbols with the breakpoint. Instead of ignoring
> the BP like older versions do, it throws a fit and forces a breakpoint you
> cannot resolve. Try doing a “bc*” in the command line to clear all your
> breakpoints, or boot to safe mode and get your SYS and PDB files in sync. If
> the trap happens in Safe Mode, and I have seen it happen, then boot to the
> repair console and disable your driver, and sync SYS/PDB. You might also try
> killing the 6.4 WinDbg session, and starting 6.3 or older, hopefully the
> older behavior will then be invoked and the BP ignored.
> The point is, you have to resolve the symbology problem, and versions
> 6.4+ do not allow you to do that, in fact they simply get in the way, so
> you have to resort to other means. At least that has been my experience with
> 6.4+.
>
> –
> The personal opinion of
> Gary G. Little
>
> “Developer” wrote in message news:xxxxx@windbg…
> I can boot the machine without any problem, however when I connect the
> debugger I get
>
> Microsoft (R) Windows Debugger Version 6.4.0007.2 http:
> Copyright (c) Microsoft Corporation. All rights reserved.
>
> Opened \.\com1
> Waiting to reconnect…
> Connected to Windows 2000 2195 x86 compatible target, ptr64 FALSE
> Kernel Debugger connection established.
> Symbol search path is: SRVc:\symserver
> http://msdl.microsoft.com/download/symbols;C:\DRV\symbolshttp:
> Executable search path is:
> Windows 2000 Kernel Version 2195 UP Free x86 compatible
> Kernel base = 0x804de000 PsLoadedModuleList = 0x805484c0
> System Uptime: not available
> Break instruction exception - code 80000003 (first chance)
> nt!DbgBreakPoint:
> 80530e64 cc int 3
>
> *** Fatal System Error: 0x0000000a
> (0x00000000,0x00000002,0x00000001,0x8050B5B4)
>
> I added a /BREAK in Boot.INI. It just won’t let me debug!
>
>
>
> –
>
> - Developer
>
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
–
- Developer</http:></http:>
And good practice: always use module qualifiers on your breakpoints (ie
- module!myfunc) to avoid symbol searching across modules.
Jason
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Tuesday, August 30, 2005 9:08 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] 0x0000000a
My experience with this same trap is a problem with the symbols. I saw
this in 6.4/5 when my symbols are out of sync with my driver and the
6.4+ debugger cannot resolve the symbols with the breakpoint. Instead of
ignoring the BP like older versions do, it throws a fit and forces a
breakpoint you cannot resolve. Try doing a “bc*” in the command line to
clear all your breakpoints, or boot to safe mode and get your SYS and
PDB files in sync. If the trap happens in Safe Mode, and I have seen it
happen, then boot to the repair console and disable your driver, and
sync SYS/PDB. You might also try killing the 6.4 WinDbg session, and
starting 6.3 or older, hopefully the older behavior will then be invoked
and the BP ignored.
The point is, you have to resolve the symbology problem, and versions
6.4+ do not allow you to do that, in fact they simply get in the way, so
you have to resort to other means. At least that has been my experience
with 6.4+.
–
The personal opinion of
Gary G. Little
“Developer” wrote in message
news:xxxxx@windbg…
I can boot the machine without any problem, however when I
connect the debugger I get
Microsoft (R) Windows Debugger Version 6.4.0007.2
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \.\com1
Waiting to reconnect…
Connected to Windows 2000 2195 x86 compatible target, ptr64
FALSE
Kernel Debugger connection established.
Symbol search path is:
SRVc:\symserverhttp://msdl.microsoft.com/download/symbols;C:\DRV\symbo
ls http:
Executable search path is:
Windows 2000 Kernel Version 2195 UP Free x86 compatible
Kernel base = 0x804de000 PsLoadedModuleList = 0x805484c0
System Uptime: not available
Break instruction exception - code 80000003 (first chance)
nt!DbgBreakPoint:
80530e64 cc int 3
*** Fatal System Error: 0x0000000a
(0x00000000,0x00000002,0x00000001,0x8050B5B4)
I added a /BREAK in Boot.INI. It just won’t let me debug!
–
- Developer
—
You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</http:>
sorry,
seems like the list manager rejected my reply, here it is again…
I always do that. Infact I always set break points with
bu modname!funcname
By the way, there is one moer issue I saw, may be I am mistaken, and it is
not a bug at all, still…
i set a break point by using bu, say
bu nt!xxxx
after the next reboot I find the break points have shifted to
ntyyyy+
I inferred that instead of storing the symbol name at that point, the break
point was set to some memory location, and may be htre kernel loaded itself
to a diff loc and thus the debugger got confused, and tried to locate the
nearest symbol to that mem address and print something,
Are you using a checked or partial checked build for NTOSKERNEL and HAL> These have a breakpoint in thatm and an assert that I have seen thrwon during boot. Without the debugger attached, the ASSERT will simply hang.
–
Gary G. Little
“Developer” wrote in message news:xxxxx@windbg…
sorry,
seems like the list manager rejected my reply, here it is again…
I always do that. Infact I always set break points with
bu modname!funcname
By the way, there is one moer issue I saw, may be I am mistaken, and it is not a bug at all, still…
i set a break point by using bu, say
bu nt!xxxx
after the next reboot I find the break points have shifted to
ntyyyy+
I inferred that instead of storing the symbol name at that point, the break point was set to some memory location, and may be htre kernel loaded itself to a diff loc and thus the debugger got confused, and tried to locate the nearest symbol to that mem address and print something,
I am useing the normal build of the OS. The problem was symbols, I don’t
know why, but WinDbg messes up with my symbols always. I had to delete the
entire symbol sirectory delete the workspace in windbg, shutdown windbg and
restart all over again to get things working.
On 8/31/05, Gary G. Little wrote:
>
> Are you using a checked or partial checked build for NTOSKERNEL and HAL>
> These have a breakpoint in thatm and an assert that I have seen thrwon
> during boot. Without the debugger attached, the ASSERT will simply hang.
>
> –
> Gary G. Little
>
> “Developer” wrote in message news:xxxxx@windbg…
> sorry,
>
> seems like the list manager rejected my reply, here it is again…
>
>
>
> I always do that. Infact I always set break points with
>
> bu modname!funcname
>
>
> By the way, there is one moer issue I saw, may be I am mistaken, and it is
> not a bug at all, still…
>
> i set a break point by using bu, say
> bu nt!xxxx
>
> after the next reboot I find the break points have shifted to
>
> ntyyyy+
>
> I inferred that instead of storing the symbol name at that point, the
> break point was set to some memory location, and may be htre kernel loaded
> itself to a diff loc and thus the debugger got confused, and tried to locate
> the nearest symbol to that mem address and print something,
>
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag argument:
> ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
–
- Developer