Hello everyone,
I am turning on the kernel debugger option in boot.ini. But I am not sure whether I should remove the option if I do not debug the target machine? Whether keep the kernel debugger option in boot.ini will make the system unstable or behaves strangely sometimes?
thanks in advance,
George
It’s been a while since I’ve used anything pre-bcd for a target, but if I recall correctly, it will
probably not boot without a debugger connected, but even if it does, breakpoints (most likely,
depending on what else you have going on, like a user mode debugger) and traps will cause the
machine to halt, so I guess these would qualify as ‘strange.’
You can and should always have more than one option in the boot.ini, so just add the debugger
option, and leave the original one alone.
Strictly speaking, a debugger connection is a security risk, but in practice, if someone can get
that close to the machine, it’s all a waste of time, so it’s not something that I would worry about
on that basis, but certainly there’s no upside to having it in production.
Again George - cart before the horse? Why don’t you learn how to use the debugger first, and worry
about this later.
Good luck,
mm
Lin George wrote:
Hello everyone,
I am turning on the kernel debugger option in boot.ini. But I am not sure whether I should remove the option if I do not debug the target machine? Whether keep the kernel debugger option in boot.ini will make the system unstable or behaves strangely sometimes?
thanks in advance,
George
Yes, Martin. I met with the machine halt problem as you mentioned, and I suspect it is kernel debugger option issue.
You mentioned “most likely, depending on what else you have going on, like a user mode debugger” – my confusion is do you mean breakpoint makes machine halt? My confusion is break point only takes effect when there is some binary under debug (with debugger attached), and break point is hit. If I just reboot the machine and with the kernel debugger option turned on, no breakpoint should take effect, so I think break point will never makes machine halt. Please correct me if I am wrong.
“more than one option in the boot.ini” – you mean we can let user select from start whether boot with kernel debugger turned on or turned off? Looks like fancy.
regards,
George
----- Original Message ----
From: Martin O’Brien
To: Kernel Debugging Interest List
Sent: Monday, November 17, 2008 8:36:06 PM
Subject: Re:[windbg] kernel debugger option
It’s been a while since I’ve used anything pre-bcd for a target, but if I recall correctly, it will probably not boot without a debugger connected, but even if it does, breakpoints (most likely, depending on what else you have going on, like a user mode debugger) and traps will cause the machine to halt, so I guess these would qualify as ‘strange.’
You can and should always have more than one option in the boot.ini, so just add the debugger option, and leave the original one alone.
Strictly speaking, a debugger connection is a security risk, but in practice, if someone can get that close to the machine, it’s all a waste of time, so it’s not something that I would worry about on that basis, but certainly there’s no upside to having it in production.
Again George - cart before the horse?? Why don’t you learn how to use the debugger first, and worry about this later.
Good luck,
mm
Lin George wrote:
> Hello everyone,
>
> I am turning on the kernel debugger option in boot.ini. But I am not sure whether I should remove the option if I do not debug the target machine? Whether keep the kernel debugger option in boot.ini will make the system unstable or behaves strangely sometimes?
>
> thanks in advance,
> George
>
>
>? ? ?
—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Yes - any breakpoint that is not handled by a user mode debugger will cause the target to
‘halt,’ because it is expecting a kernel debugger to be connected. I haven’t any idea of what
you’re talking about with the rest of that, but there events in the os itself that cause
breakpoints, and there’s also third party software that behaves very differently with a
configuration that enabled /debug support, so it’s not something that you can control, especially in
the case of CHK builds.
Read the documentation. Please. All you have to do is copy the existing line to a new line and
modify it, but, again, read the documentation, please.
Both of those being said, it doesn’t matter, given what you have experienced yourself:
Yes, Martin. I met with the machine halt problem as you mentioned, and I suspect it is kernel
debugger option issue.
Doesn’t this settle the question for you? Why does it matter if you can’t even boot without a
debugger enabled, and no, it’s not an option problem, unless you mean not enabling debugging as the
‘option.’
George, you need to understand that learning how to use windbg for kernel work takes a good three to
six months to figure out, and that assumes that you know something about kernel work to begin with.
There are no tutorials for learning kd debugging, the documentation deeply, deeply sucks, and
there is no way to learn it other than to just roll up your sleeves and do it. You. Not me. Not
Tim. Not Skywing. Not Snoone. Not raj_r. Not anyone else. You. This subject (how to use windbg
for kd) is one of the most common questions on these lists, and because of that and that there is no
answer other than ‘do it yourself,’ it’s also one of the questions for which members have the least
patience.
Do with this piece of advice what you will, but given what you have shown us to date, you don’t seem
to be willing to figure things out on your own, and you also don’t generally like what we tell you,
so I really, really, really don’t think you’re going to like this type of work.
Good luck,
mm
Lin George wrote:
Yes, Martin. I met with the machine halt problem as you mentioned, and I suspect it is kernel debugger option issue.
You mentioned “most likely, depending on what else you have going on, like a user mode debugger” – my confusion is do you mean breakpoint makes machine halt? My confusion is break point only takes effect when there is some binary under debug (with debugger attached), and break point is hit. If I just reboot the machine and with the kernel debugger option turned on, no breakpoint should take effect, so I think break point will never makes machine halt. Please correct me if I am wrong.
“more than one option in the boot.ini” – you mean we can let user select from start whether boot with kernel debugger turned on or turned off? Looks like fancy.
regards,
George----- Original Message ----
From: Martin O’Brien
> To: Kernel Debugging Interest List
> Sent: Monday, November 17, 2008 8:36:06 PM
> Subject: Re:[windbg] kernel debugger option
>
> It’s been a while since I’ve used anything pre-bcd for a target, but if I recall correctly, it will probably not boot without a debugger connected, but even if it does, breakpoints (most likely, depending on what else you have going on, like a user mode debugger) and traps will cause the machine to halt, so I guess these would qualify as ‘strange.’
>
> You can and should always have more than one option in the boot.ini, so just add the debugger option, and leave the original one alone.
>
> Strictly speaking, a debugger connection is a security risk, but in practice, if someone can get that close to the machine, it’s all a waste of time, so it’s not something that I would worry about on that basis, but certainly there’s no upside to having it in production.
>
> Again George - cart before the horse? Why don’t you learn how to use the debugger first, and worry about this later.
>
>
> Good luck,
>
> mm
>
> Lin George wrote:
>> Hello everyone,
>>
>> I am turning on the kernel debugger option in boot.ini. But I am not sure whether I should remove the option if I do not debug the target machine? Whether keep the kernel debugger option in boot.ini will make the system unstable or behaves strangely sometimes?
>>
>> thanks in advance,
>> George
>>
>>
>>
>
> —
> You are currently subscribed to windbg as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>
Thanks for your advice, Martin!
Previously I think breakpoint is set by a debugger and breakpoint only effects if the binary is attached with debugger, if no debugger attached, no breakpoint will take effect. Is that true?
I am confused about what do you mean “any breakpoint that is not handled by a user mode debugger” – my confusion is, if the user mode debugger set the breakpoint, say break in main function, the user mode debugger should be able to handle this breakpoint (I think user mode debugger should be able to handle all breakpoints which is listed in bl command in Windbg). Could you show me a sample which user mode debugger sets a breakpoint, but not handle the breakpoint?
“there events in the os itself that cause breakpoints” – do you mean int 3 interruption from some software (the running software is not attached with user mode debugger but emit int 3 interruption, so the software is supposed to delegate kernel debugger to handle, and if no kernel debugger from host machie, the target machine is hang)? Or you mean something else?
BTW: why I ask this question is I want to make it clear whether it is my program bug which causes system halt or just open kernel debugger issue which causes system halt.
regards,
George
----- Original Message ----
From: Martin O’Brien
To: Kernel Debugging Interest List
Sent: Monday, November 17, 2008 9:10:27 PM
Subject: Re:[windbg] kernel debugger option
1.? Yes - any breakpoint that is not handled by a user mode debugger will cause the target to ‘halt,’ because it is expecting a kernel debugger to be connected.? I haven’t any idea of what you’re talking about with the rest of that, but there events in the os itself that cause breakpoints, and there’s also third party software that behaves very differently with a configuration that enabled /debug support, so it’s not something that you can control, especially in the case of CHK builds.
2.? Read the documentation.? Please.? All you have to do is copy the existing line to a new line and modify it, but, again, read the documentation, please.
Both of those being said, it doesn’t matter, given what you have experienced yourself:
> Yes, Martin. I met with the machine halt problem as you mentioned, and I suspect it is kernel debugger option issue.
Doesn’t this settle the question for you?? Why does it matter if you can’t even boot without a debugger enabled, and no, it’s not an option problem, unless you mean not enabling debugging as the ‘option.’
George, you need to understand that learning how to use windbg for kernel work takes a good three to six months to figure out, and that assumes that you know something about kernel work to begin with.? ? There are no tutorials for learning kd debugging, the documentation deeply, deeply sucks, and there is no way to learn it other than to just roll up your sleeves and do it.? You.? Not me.? Not Tim.? Not Skywing.? Not Snoone.? Not raj_r.? Not anyone else.? You.? This subject (how to use windbg for kd) is one of the most common questions on these lists, and because of that and that there is no answer other than ‘do it yourself,’ it’s also one of the questions for which members have the least patience.
Do with this piece of advice what you will, but given what you have shown us to date, you don’t seem to be willing to figure things out on your own, and you also don’t generally like what we tell you, so I really, really, really don’t think you’re going to like this type of work.
Good luck,
mm
Lin George wrote:
> Yes, Martin. I met with the machine halt problem as you mentioned, and I suspect it is kernel debugger option issue.
>
> 1. You mentioned “most likely, depending on what else you have going on, like a user mode debugger” – my confusion is do you mean breakpoint makes machine halt? My confusion is break point only takes effect when there is some binary under debug (with debugger attached), and break point is hit. If I just reboot the machine and with the kernel debugger option turned on, no breakpoint should take effect, so I think break point will never makes machine halt. Please correct me if I am wrong.
>
> 2. “more than one option in the boot.ini” – you mean we can let user select from start whether boot with kernel debugger turned on or turned off? Looks like fancy.
>
> regards,
> George
>
>
> ----- Original Message ----
> From: Martin O’Brien
> To: Kernel Debugging Interest List
> Sent: Monday, November 17, 2008 8:36:06 PM
> Subject: Re:[windbg] kernel debugger option
>
> It’s been a while since I’ve used anything pre-bcd for a target, but if I recall correctly, it will probably not boot without a debugger connected, but even if it does, breakpoints (most likely, depending on what else you have going on, like a user mode debugger) and traps will cause the machine to halt, so I guess these would qualify as ‘strange.’
>
> You can and should always have more than one option in the boot.ini, so just add the debugger option, and leave the original one alone.
>
> Strictly speaking, a debugger connection is a security risk, but in practice, if someone can get that close to the machine, it’s all a waste of time, so it’s not something that I would worry about on that basis, but certainly there’s no upside to having it in production.
>
> Again George - cart before the horse?? Why don’t you learn how to use the debugger first, and worry about this later.
>
>
> Good luck,
>
> mm
>
> Lin George wrote:
>> Hello everyone,
>>
>> I am turning on the kernel debugger option in boot.ini. But I am not sure whether I should remove the option if I do not debug the target machine? Whether keep the kernel debugger option in boot.ini will make the system unstable or behaves strangely sometimes?
>>
>> thanks in advance,
>> George
>>
>>
>>? ? ?
>
> —
> You are currently subscribed to windbg as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>? ? ?
—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Lin George wrote:
Hello everyone,
I am turning on the kernel debugger option in boot.ini. But I am not sure whether I should remove the option if I do not debug the target machine? Whether keep the kernel debugger option in boot.ini will make the system unstable or behaves strangely sometimes?
thanks in advance,
George
George,
Welcome to windbg newsgroup (albeit I’m typing this with somewhat mixed
feelings…)
Yes, if you don’t run the target under kernel debugger, better remove
debugger options from boot.ini.
If you leave debugger options there, but the host debugger is not
connected, Windows possibly will timeout and continue booting.
But the debugger is still active. If the code hits a breakpoint, it will
hang (wait for debugger) rather than crash.
Good luck,
–PA
> 1. Yes - any breakpoint that is not handled by a user mode debugger will
cause the target to ‘halt,’ because it is expecting a kernel debugger to
be connected.
You can actually control this behavior with kdbgctrl, which is handy if you
want to boot your workstation with /debug. Requires Server 2003 and later
though,
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Martin O’Brien” wrote in message
news:xxxxx@windbg…
> 1. Yes - any breakpoint that is not handled by a user mode debugger will
> cause the target to ‘halt,’ because it is expecting a kernel debugger to
> be connected. I haven’t any idea of what you’re talking about with the
> rest of that, but there events in the os itself that cause breakpoints,
> and there’s also third party software that behaves very differently with a
> configuration that enabled /debug support, so it’s not something that you
> can control, especially in the case of CHK builds.
>
> 2. Read the documentation. Please. All you have to do is copy the
> existing line to a new line and modify it, but, again, read the
> documentation, please.
>
> Both of those being said, it doesn’t matter, given what you have
> experienced yourself:
>
> > Yes, Martin. I met with the machine halt problem as you mentioned, and I
> > suspect it is kernel
> debugger option issue.
>
> Doesn’t this settle the question for you? Why does it matter if you can’t
> even boot without a debugger enabled, and no, it’s not an option problem,
> unless you mean not enabling debugging as the ‘option.’
>
> George, you need to understand that learning how to use windbg for kernel
> work takes a good three to six months to figure out, and that assumes that
> you know something about kernel work to begin with. There are no tutorials
> for learning kd debugging, the documentation deeply, deeply sucks, and
> there is no way to learn it other than to just roll up your sleeves and do
> it. You. Not me. Not Tim. Not Skywing. Not Snoone. Not raj_r. Not
> anyone else. You. This subject (how to use windbg for kd) is one of the
> most common questions on these lists, and because of that and that there
> is no answer other than ‘do it yourself,’ it’s also one of the questions
> for which members have the least patience.
>
> Do with this piece of advice what you will, but given what you have shown
> us to date, you don’t seem to be willing to figure things out on your own,
> and you also don’t generally like what we tell you, so I really, really,
> really don’t think you’re going to like this type of work.
>
>
> Good luck,
>
> mm
>
>
>
>
>
>
>
>
>
>
>
>
> Lin George wrote:
>> Yes, Martin. I met with the machine halt problem as you mentioned, and I
>> suspect it is kernel debugger option issue.
>>
>> 1. You mentioned “most likely, depending on what else you have going on,
>> like a user mode debugger” – my confusion is do you mean breakpoint
>> makes machine halt? My confusion is break point only takes effect when
>> there is some binary under debug (with debugger attached), and break
>> point is hit. If I just reboot the machine and with the kernel debugger
>> option turned on, no breakpoint should take effect, so I think break
>> point will never makes machine halt. Please correct me if I am wrong.
>>
>> 2. “more than one option in the boot.ini” – you mean we can let user
>> select from start whether boot with kernel debugger turned on or turned
>> off? Looks like fancy.
>>
>> regards,
>> George
>>
>>
>> ----- Original Message ----
>> From: Martin O’Brien
>> To: Kernel Debugging Interest List
>> Sent: Monday, November 17, 2008 8:36:06 PM
>> Subject: Re:[windbg] kernel debugger option
>>
>> It’s been a while since I’ve used anything pre-bcd for a target, but if I
>> recall correctly, it will probably not boot without a debugger connected,
>> but even if it does, breakpoints (most likely, depending on what else you
>> have going on, like a user mode debugger) and traps will cause the
>> machine to halt, so I guess these would qualify as ‘strange.’
>>
>> You can and should always have more than one option in the boot.ini, so
>> just add the debugger option, and leave the original one alone.
>>
>> Strictly speaking, a debugger connection is a security risk, but in
>> practice, if someone can get that close to the machine, it’s all a waste
>> of time, so it’s not something that I would worry about on that basis,
>> but certainly there’s no upside to having it in production.
>>
>> Again George - cart before the horse? Why don’t you learn how to use the
>> debugger first, and worry about this later.
>>
>>
>> Good luck,
>>
>> mm
>>
>> Lin George wrote:
>>> Hello everyone,
>>>
>>> I am turning on the kernel debugger option in boot.ini. But I am not
>>> sure whether I should remove the option if I do not debug the target
>>> machine? Whether keep the kernel debugger option in boot.ini will make
>>> the system unstable or behaves strangely sometimes?
>>>
>>> thanks in advance,
>>> George
>>>
>>>
>>>
>>
>> —
>> You are currently subscribed to windbg as: xxxxx@yahoo.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>>
>
Note that you need to not have the debugger connected at boot time or it will be flagged as present, and thus things like kernel mode image loads will trigger blocking kd communication.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Monday, November 17, 2008 10:41 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] kernel debugger option
- Yes - any breakpoint that is not handled by a user mode debugger will
cause the target to ‘halt,’ because it is expecting a kernel debugger to
be connected.
You can actually control this behavior with kdbgctrl, which is handy if you
want to boot your workstation with /debug. Requires Server 2003 and later
though,
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Martin O’Brien” wrote in message
news:xxxxx@windbg…
> 1. Yes - any breakpoint that is not handled by a user mode debugger will
> cause the target to ‘halt,’ because it is expecting a kernel debugger to
> be connected. I haven’t any idea of what you’re talking about with the
> rest of that, but there events in the os itself that cause breakpoints,
> and there’s also third party software that behaves very differently with a
> configuration that enabled /debug support, so it’s not something that you
> can control, especially in the case of CHK builds.
>
> 2. Read the documentation. Please. All you have to do is copy the
> existing line to a new line and modify it, but, again, read the
> documentation, please.
>
> Both of those being said, it doesn’t matter, given what you have
> experienced yourself:
>
> > Yes, Martin. I met with the machine halt problem as you mentioned, and I
> > suspect it is kernel
> debugger option issue.
>
> Doesn’t this settle the question for you? Why does it matter if you can’t
> even boot without a debugger enabled, and no, it’s not an option problem,
> unless you mean not enabling debugging as the ‘option.’
>
> George, you need to understand that learning how to use windbg for kernel
> work takes a good three to six months to figure out, and that assumes that
> you know something about kernel work to begin with. There are no tutorials
> for learning kd debugging, the documentation deeply, deeply sucks, and
> there is no way to learn it other than to just roll up your sleeves and do
> it. You. Not me. Not Tim. Not Skywing. Not Snoone. Not raj_r. Not
> anyone else. You. This subject (how to use windbg for kd) is one of the
> most common questions on these lists, and because of that and that there
> is no answer other than ‘do it yourself,’ it’s also one of the questions
> for which members have the least patience.
>
> Do with this piece of advice what you will, but given what you have shown
> us to date, you don’t seem to be willing to figure things out on your own,
> and you also don’t generally like what we tell you, so I really, really,
> really don’t think you’re going to like this type of work.
>
>
> Good luck,
>
> mm
>
>
>
>
>
>
>
>
>
>
>
>
> Lin George wrote:
>> Yes, Martin. I met with the machine halt problem as you mentioned, and I
>> suspect it is kernel debugger option issue.
>>
>> 1. You mentioned “most likely, depending on what else you have going on,
>> like a user mode debugger” – my confusion is do you mean breakpoint
>> makes machine halt? My confusion is break point only takes effect when
>> there is some binary under debug (with debugger attached), and break
>> point is hit. If I just reboot the machine and with the kernel debugger
>> option turned on, no breakpoint should take effect, so I think break
>> point will never makes machine halt. Please correct me if I am wrong.
>>
>> 2. “more than one option in the boot.ini” – you mean we can let user
>> select from start whether boot with kernel debugger turned on or turned
>> off? Looks like fancy.
>>
>> regards,
>> George
>>
>>
>> ----- Original Message ----
>> From: Martin O’Brien
>> To: Kernel Debugging Interest List
>> Sent: Monday, November 17, 2008 8:36:06 PM
>> Subject: Re:[windbg] kernel debugger option
>>
>> It’s been a while since I’ve used anything pre-bcd for a target, but if I
>> recall correctly, it will probably not boot without a debugger connected,
>> but even if it does, breakpoints (most likely, depending on what else you
>> have going on, like a user mode debugger) and traps will cause the
>> machine to halt, so I guess these would qualify as ‘strange.’
>>
>> You can and should always have more than one option in the boot.ini, so
>> just add the debugger option, and leave the original one alone.
>>
>> Strictly speaking, a debugger connection is a security risk, but in
>> practice, if someone can get that close to the machine, it’s all a waste
>> of time, so it’s not something that I would worry about on that basis,
>> but certainly there’s no upside to having it in production.
>>
>> Again George - cart before the horse? Why don’t you learn how to use the
>> debugger first, and worry about this later.
>>
>>
>> Good luck,
>>
>> mm
>>
>> Lin George wrote:
>>> Hello everyone,
>>>
>>> I am turning on the kernel debugger option in boot.ini. But I am not
>>> sure whether I should remove the option if I do not debug the target
>>> machine? Whether keep the kernel debugger option in boot.ini will make
>>> the system unstable or behaves strangely sometimes?
>>>
>>> thanks in advance,
>>> George
>>>
>>>
>>>
>>
>> —
>> You are currently subscribed to windbg as: xxxxx@yahoo.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>>
>
—
You are currently subscribed to windbg as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
here is what windbg help file has to offer for your questions
The most common application errors are called exceptions. These include
access violations, division-by-zero errors, numerical overflows, and many
other kinds of errors.
Applications can also cause breakpoint interrupts. These occur when Windows
is unable to run the application (for example, when a necessary module
cannot be loaded) or when a breakpoint is encountered. Breakpoints can be
inserted into the code by a debugger, or invoked through a function such as
DbgBreakPoint. In assembly language, a breakpoint interrupt is generated by
an int 3 instruction.
Windows can handle user-mode errors in a variety of ways. The following
sequence shows the precedence used for error handling:
If a user-mode debugger is currently attached to the faulting process, all
errors will cause the target to break into this debugger.
As long as the user-mode debugger is attached, no other error-handling
methods will be used ? even if the gn (Go With Exception Not Handled)
command is used.
*If no user-mode debugger is attached and the executing code has its own
exception handling routines (for example, try - except), this exception
handling routine will attempt to deal with the error.
*If no user-mode debugger is attached, and Windows has an open
kernel-debugging connection, and the error is a breakpoint interrupt,
Windows will attempt to contact the kernel debugger.
Kernel debugging connections must be opened during Windows’ boot process. If
you are using Windows Server 2003 or a later version of Windows and wish to
prevent a user-mode interrupt from breaking into the kernel debugger, you
can use the KDbgCtrl utility with the -du parameter. For details on how to
configure kernel-debugging connections and how to use KDbgCtrl, see
Configuring Software on the Target Computer.
*If Windows does attempt to contact a kernel debugger but there is no
debugger running at the other end of the connection, Windows will freeze
until kernel debugger is activated.
*
In the kernel debugger, you can use gh (Go With Exception Handled) to
disregard the error and continue running the target. You can use gn (Go With
Exception Not Handled) to bypass the kernel debugger and go on to step 4.
If the conditions in steps 1, 2, and 3 do not apply, Windows will activate a
debugging tool. Any program can be selected in advance as the tool to use in
this situation. The chosen program is referred to as the postmortem
debugger. This is also known as the just-in-time debugger or the JIT
debugger.
If the postmortem debugger is a standard user-mode debugger (such as CDB,
WinDbg, or Microsoft Visual Studio), this debugger will start up and break
into your application.
If the postmortem debugger is a tool for writing dump files (such as Dr.
Watson), a memory dump file will be created, and then the application will
be terminated.
Note If Dr. Watson is activated on Windows XP or a later version of
Windows, a message box will appear. This window gives you the option of
sending an error report to Microsoft. If you choose Don’t Send, a dump file
will created and stored on your hard disk. If you choose Send Error Report,
a dump file will be created and stored on your hard disk, and will also be
transmitted to Microsoft over the internet.
If you have not reconfigured Windows’ postmortem settings, Dr. Watson is
used as the default postmortem debugger. This setting can be changed
programmatically or through the registry; any changes take effect
immediately.
To change the postmortem debugger to WinDbg, run windbg -I. (The I must be
capitalized.) This command will display a success or failure message after
it is used. When WinDbg is the postmortem debugger, it will be activated
whenever an application crashes.
To change the postmortem debugger to CDB, run cdb -iae or cdb -iaec
KeyString… When the -iaec switch is used, KeyString specifies a string to
be added to the end of the AeDebug registry key. This command will display
no message if it succeeds, but will display a failure message if it fails.
When CDB is the postmortem debugger, it will be activated whenever an
application crashes.
To change the postmortem debugger to NTSD, run ntsd -iae or ntsd -iaec
KeyString… When the -iaec switch is used, KeyString specifies a string to
be added to the end of the AeDebug registry key. If KeyString contains
spaces, it must be enclosed in quotation marks. This command will display no
message if it succeeds, but will display a failure message if it fails. When
NTSD is the postmortem debugger, it will be activated whenever an
application crashes.
To change the postmortem debugger back to Dr. Watson, run drwtsn32 -i. When
Dr. Watson is the postmortem debugger, a memory dump file will be written to
disk if an application crashes. See Dr. Watson Command-Line Options for
details.
Only a system administrator can alter the postmortem settings.
If a postmortem debugger has been installed, you can deliberately break into
the debugger from a user-mode application by calling the DebugBreak
function.
like it has been stated several times earlier there is no better way other
than do it yourself
and read and reread the windbg help file until things start making sense on
your own
scott noone or for that matter anyone who is reading or responding to this
list probably might never need to use usermode debugging
but they still know it in back of thier mind how to enable or disable user
mode exception and they also post the os that this option works
thats mainly because they might have glanced over the help file quiet a few
times just reading it like a novel
try searching for *noumex *switch as an added trivia to the debugger
handling user mode exceptions
regards
raj_r
On 11/17/08, Lin George wrote:
> Thanks for your advice, Martin!
>
> 1.
>
> Previously I think breakpoint is set by a debugger and breakpoint only
effects if the binary is attached with debugger, if no debugger attached, no
breakpoint will take effect. Is that true?
>
> 2.
>
> I am confused about what do you mean “any breakpoint that is not handled
by a user mode debugger” – my confusion is, if the user mode debugger set
the breakpoint, say break in main function, the user mode debugger should be
able to handle this breakpoint (I think user mode debugger should be able to
handle all breakpoints which is listed in bl command in Windbg). Could you
show me a sample which user mode debugger sets a breakpoint, but not handle
the breakpoint?
>
> 3.
>
> “there events in the os itself that cause breakpoints” – do you mean int
3 interruption from some software (the running software is not attached with
user mode debugger but emit int 3 interruption, so the software is supposed
to delegate kernel debugger to handle, and if no kernel debugger from host
machie, the target machine is hang)? Or you mean something else?
>
> BTW: why I ask this question is I want to make it clear whether it is my
program bug which causes system halt or just open kernel debugger issue
which causes system halt.
>
> regards,
> George
>
>
> ----- Original Message ----
> From: Martin O’Brien
> To: Kernel Debugging Interest List
> Sent: Monday, November 17, 2008 9:10:27 PM
> Subject: Re:[windbg] kernel debugger option
>
> 1. Yes - any breakpoint that is not handled by a user mode debugger will
cause the target to ‘halt,’ because it is expecting a kernel debugger to be
connected. I haven’t any idea of what you’re talking about with the rest of
that, but there events in the os itself that cause breakpoints, and there’s
also third party software that behaves very differently with a configuration
that enabled /debug support, so it’s not something that you can control,
especially in the case of CHK builds.
>
> 2. Read the documentation. Please. All you have to do is copy the
existing line to a new line and modify it, but, again, read the
documentation, please.
>
> Both of those being said, it doesn’t matter, given what you have
experienced yourself:
>
> > Yes, Martin. I met with the machine halt problem as you mentioned, and I
suspect it is kernel debugger option issue.
>
> Doesn’t this settle the question for you? Why does it matter if you can’t
even boot without a debugger enabled, and no, it’s not an option problem,
unless you mean not enabling debugging as the ‘option.’
>
> George, you need to understand that learning how to use windbg for kernel
work takes a good three to six months to figure out, and that assumes that
you know something about kernel work to begin with. There are no
tutorials for learning kd debugging, the documentation deeply, deeply sucks,
and there is no way to learn it other than to just roll up your sleeves and
do it. You. Not me. Not Tim. Not Skywing. Not Snoone. Not raj_r. Not
anyone else. You. This subject (how to use windbg for kd) is one of the
most common questions on these lists, and because of that and that there is
no answer other than ‘do it yourself,’ it’s also one of the questions for
which members have the least patience.
>
> Do with this piece of advice what you will, but given what you have shown
us to date, you don’t seem to be willing to figure things out on your own,
and you also don’t generally like what we tell you, so I really, really,
really don’t think you’re going to like this type of work.
>
>
> Good luck,
>
> mm
>
>
>
>
>
>
>
>
>
>
>
>
> Lin George wrote:
> > Yes, Martin. I met with the machine halt problem as you mentioned, and I
suspect it is kernel debugger option issue.
> >
> > 1. You mentioned “most likely, depending on what else you have going on,
like a user mode debugger” – my confusion is do you mean breakpoint makes
machine halt? My confusion is break point only takes effect when there is
some binary under debug (with debugger attached), and break point is hit. If
I just reboot the machine and with the kernel debugger option turned on, no
breakpoint should take effect, so I think break point will never makes
machine halt. Please correct me if I am wrong.
> >
> > 2. “more than one option in the boot.ini” – you mean we can let user
select from start whether boot with kernel debugger turned on or turned off?
Looks like fancy.
> >
> > regards,
> > George
> >
> >
> > ----- Original Message ----
> > From: Martin O’Brien
> > To: Kernel Debugging Interest List
> > Sent: Monday, November 17, 2008 8:36:06 PM
> > Subject: Re:[windbg] kernel debugger option
> >
> > It’s been a while since I’ve used anything pre-bcd for a target, but if
I recall correctly, it will probably not boot without a debugger connected,
but even if it does, breakpoints (most likely, depending on what else you
have going on, like a user mode debugger) and traps will cause the machine
to halt, so I guess these would qualify as ‘strange.’
> >
> > You can and should always have more than one option in the boot.ini, so
just add the debugger option, and leave the original one alone.
> >
> > Strictly speaking, a debugger connection is a security risk, but in
practice, if someone can get that close to the machine, it’s all a waste of
time, so it’s not something that I would worry about on that basis, but
certainly there’s no upside to having it in production.
> >
> > Again George - cart before the horse? Why don’t you learn how to use
the debugger first, and worry about this later.
> >
> >
> > Good luck,
> >
> > mm
> >
> > Lin George wrote:
> >> Hello everyone,
> >>
> >> I am turning on the kernel debugger option in boot.ini. But I am not
sure whether I should remove the option if I do not debug the target
machine? Whether keep the kernel debugger option in boot.ini will make the
system unstable or behaves strangely sometimes?
> >>
> >> thanks in advance,
> >> George
> >>
> >>
> >>
> >
> > —
> > You are currently subscribed to windbg as: xxxxx@yahoo.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >
>
> —
> You are currently subscribed to windbg as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
Hi PA,
You are good guy here. 
“If you leave debugger options there, but the host debugger is not connected, Windows possibly will timeout and continue booting.”
I am under pressure that other people say it is my bug. But I suspect it is kernel debugger issue – which cause machine halt/reboot. So, you mean even if there is no breakpoint hit, if I enable kernel debugger in boot.ini, during start of the machine, it will wait for the connection from debugging host machine? If no debugging host machine connection comes in, the machine will reboot? Is that your point?
I did search in Windbg help document but have not found your claims above, do you have any documents to support your statements?
“But the debugger is still active. If the code hits a breakpoint, it will hang (wait for debugger) rather than crash.”
I do not know what do you mean debugger is still active. I have never opened ntsd/kd/Windbg/Visual Studio on the machine, does it mean debugger will not be active and breakpoint hit issue (which cause machine hang) you mentioned above will never happen?
regards,
George
----- Original Message ----
From: Pavel A.
To: Kernel Debugging Interest List
Sent: Monday, November 17, 2008 11:09:11 PM
Subject: Re:[windbg] kernel debugger option
Lin George wrote:
> Hello everyone,
>
> I am turning on the kernel debugger option in boot.ini. But I am not sure whether I should remove the option if I do not debug the target machine? Whether keep the kernel debugger option in boot.ini will make the system unstable or behaves strangely sometimes?
>
> thanks in advance,
> George
George,
Welcome to windbg newsgroup (albeit I’m typing this with somewhat mixed feelings…)
Yes, if you don’t run the target under kernel debugger, better remove debugger options from boot.ini.
If you leave debugger options there, but the host debugger is not connected, Windows possibly will timeout and continue booting.
But the debugger is still active. If the code hits a breakpoint, it will hang (wait for debugger) rather than crash.
Good luck,
–PA
—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Scott,
On the specific machine which I turn on kernel debugger option in boot.ini, I do not run any program under debugger (ntsd/kd/Windbg/Visual Studio). I think in this situation, there is no breakpoint issue? My understanding is breakpoint only take effects and be able to set when we run application under debugger?
regards,
George
----- Original Message ----
From: Scott Noone
To: Kernel Debugging Interest List
Sent: Monday, November 17, 2008 11:40:50 PM
Subject: Re:[windbg] kernel debugger option
> 1.? Yes - any breakpoint that is not handled by a user mode debugger will
> cause the target to ‘halt,’ because it is expecting a kernel debugger to
> be connected.
You can actually control this behavior with kdbgctrl, which is handy if you
want to boot your workstation with /debug. Requires Server 2003 and later
though,
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Martin O’Brien” wrote in message
news:xxxxx@windbg…
> 1.? Yes - any breakpoint that is not handled by a user mode debugger will
> cause the target to ‘halt,’ because it is expecting a kernel debugger to
> be connected.? I haven’t any idea of what you’re talking about with the
> rest of that, but there events in the os itself that cause breakpoints,
> and there’s also third party software that behaves very differently with a
> configuration that enabled /debug support, so it’s not something that you
> can control, especially in the case of CHK builds.
>
> 2.? Read the documentation.? Please.? All you have to do is copy the
> existing line to a new line and modify it, but, again, read the
> documentation, please.
>
> Both of those being said, it doesn’t matter, given what you have
> experienced yourself:
>
> > Yes, Martin. I met with the machine halt problem as you mentioned, and I
> > suspect it is kernel
> debugger option issue.
>
> Doesn’t this settle the question for you?? Why does it matter if you can’t
> even boot without a debugger enabled, and no, it’s not an option problem,
> unless you mean not enabling debugging as the ‘option.’
>
> George, you need to understand that learning how to use windbg for kernel
> work takes a good three to six months to figure out, and that assumes that
> you know something about kernel work to begin with. There are no tutorials
> for learning kd debugging, the documentation deeply, deeply sucks, and
> there is no way to learn it other than to just roll up your sleeves and do
> it.? You.? Not me.? Not Tim.? Not Skywing.? Not Snoone.? Not raj_r.? Not
> anyone else.? You.? This subject (how to use windbg for kd) is one of the
> most common questions on these lists, and because of that and that there
> is no answer other than ‘do it yourself,’ it’s also one of the questions
> for which members have the least patience.
>
> Do with this piece of advice what you will, but given what you have shown
> us to date, you don’t seem to be willing to figure things out on your own,
> and you also don’t generally like what we tell you, so I really, really,
> really don’t think you’re going to like this type of work.
>
>
> Good luck,
>
> mm
>
>
>
>
>
>
>
>
>
>
>
>
> Lin George wrote:
>> Yes, Martin. I met with the machine halt problem as you mentioned, and I
>> suspect it is kernel debugger option issue.
>>
>> 1. You mentioned “most likely, depending on what else you have going on,
>> like a user mode debugger” – my confusion is do you mean breakpoint
>> makes machine halt? My confusion is break point only takes effect when
>> there is some binary under debug (with debugger attached), and break
>> point is hit. If I just reboot the machine and with the kernel debugger
>> option turned on, no breakpoint should take effect, so I think break
>> point will never makes machine halt. Please correct me if I am wrong.
>>
>> 2. “more than one option in the boot.ini” – you mean we can let user
>> select from start whether boot with kernel debugger turned on or turned
>> off? Looks like fancy.
>>
>> regards,
>> George
>>
>>
>> ----- Original Message ----
>> From: Martin O’Brien
>> To: Kernel Debugging Interest List
>> Sent: Monday, November 17, 2008 8:36:06 PM
>> Subject: Re:[windbg] kernel debugger option
>>
>> It’s been a while since I’ve used anything pre-bcd for a target, but if I
>> recall correctly, it will probably not boot without a debugger connected,
>> but even if it does, breakpoints (most likely, depending on what else you
>> have going on, like a user mode debugger) and traps will cause the
>> machine to halt, so I guess these would qualify as ‘strange.’
>>
>> You can and should always have more than one option in the boot.ini, so
>> just add the debugger option, and leave the original one alone.
>>
>> Strictly speaking, a debugger connection is a security risk, but in
>> practice, if someone can get that close to the machine, it’s all a waste
>> of time, so it’s not something that I would worry about on that basis,
>> but certainly there’s no upside to having it in production.
>>
>> Again George - cart before the horse?? Why don’t you learn how to use the
>> debugger first, and worry about this later.
>>
>>
>> Good luck,
>>
>> mm
>>
>> Lin George wrote:
>>> Hello everyone,
>>>
>>> I am turning on the kernel debugger option in boot.ini. But I am not
>>> sure whether I should remove the option if I do not debug the target
>>> machine? Whether keep the kernel debugger option in boot.ini will make
>>> the system unstable or behaves strangely sometimes?
>>>
>>> thanks in advance,
>>> George
>>>
>>>
>>>
>>
>> —
>> You are currently subscribed to windbg as: xxxxx@yahoo.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>>
>
—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Thanks raj_r,
?
I find your referred document in Windbg help document post mortem debugger section. I have also read related other sections.
?
My current confusion is, I do not know my situation matches which category or steps (1-4 from the document you recommended below).
?
In step 3, it is mentioned, “If no user-mode debugger is attached, and Windows has an open kernel-debugging connection, and the error is a breakpoint interrupt, Windows will attempt to contact the kernel debugger.” – my situation is, I only turn on the kernel debugger option in boot.ini, no actual kernel debugger host connected. In this situation, does Windows treat it as there is an open kernel-debugging connection and will wait forever for the non-existing debugger host to connect – which causes machine hang?
?
regards,
George
From: raj_r
To: Kernel Debugging Interest List
Sent: Tuesday, November 18, 2008 1:47:06 AM
Subject: Re: [windbg] kernel debugger option
here is what windbg help file has to offer for your questions
The most common application errors are called exceptions. These include access violations, division-by-zero errors, numerical overflows, and many other kinds of errors.
Applications can also cause breakpoint interrupts. These occur when Windows is unable to run the application (for example, when a necessary module cannot be loaded) or when a breakpoint is encountered. Breakpoints can be inserted into the code by a debugger, or invoked through a function such as DbgBreakPoint. In assembly language, a breakpoint interrupt is generated by an int 3 instruction.
Windows can handle user-mode errors in a variety of ways. The following sequence shows the precedence used for error handling:
If a user-mode debugger is currently attached to the faulting process, all errors will cause the target to break into this debugger.
As long as the user-mode debugger is attached, no other error-handling methods will be used ? even if the gn (Go With Exception Not Handled) command is used.
If no user-mode debugger is attached and the executing code has its own exception handling routines (for example, try - except), this exception handling routine will attempt to deal with the error.
If no user-mode debugger is attached, and Windows has an open kernel-debugging connection, and the error is a breakpoint interrupt, Windows will attempt to contact the kernel debugger.
Kernel debugging connections must be opened during Windows’ boot process. If you are using Windows Server 2003 or a later version of Windows and wish to prevent a user-mode interrupt from breaking into the kernel debugger, you can use the KDbgCtrl utility with the -du parameter. For details on how to configure kernel-debugging connections and how to use KDbgCtrl, see Configuring Software on the Target Computer.
If Windows does attempt to contact a kernel debugger but there is no debugger running at the other end of the connection, Windows will freeze until kernel debugger is activated.
In the kernel debugger, you can use gh (Go With Exception Handled) to disregard the error and continue running the target. You can use gn (Go With Exception Not Handled) to bypass the kernel debugger and go on to step 4.
If the conditions in steps 1, 2, and 3 do not apply, Windows will activate a debugging tool. Any program can be selected in advance as the tool to use in this situation. The chosen program is referred to as the postmortem debugger. This is also known as the just-in-time debugger or the JIT debugger.
If the postmortem debugger is a standard user-mode debugger (such as CDB, WinDbg, or Microsoft Visual Studio), this debugger will start up and break into your application.
If the postmortem debugger is a tool for writing dump files (such as Dr. Watson), a memory dump file will be created, and then the application will be terminated.
Note??If Dr. Watson is activated on Windows XP or a later version of Windows, a message box will appear. This window gives you the option of sending an error report to Microsoft. If you choose Don’t Send, a dump file will created and stored on your hard disk. If you choose Send Error Report, a dump file will be created and stored on your hard disk, and will also be transmitted to Microsoft over the internet.
If you have not reconfigured Windows’ postmortem settings, Dr. Watson is used as the default postmortem debugger. This setting can be changed programmatically or through the registry; any changes take effect immediately.
To change the postmortem debugger to WinDbg, run windbg -I. (The I must be capitalized.) This command will display a success or failure message after it is used. When WinDbg is the postmortem debugger, it will be activated whenever an application crashes.
To change the postmortem debugger to CDB, run cdb -iae or cdb -iaec KeyString… When the -iaec switch is used, KeyString specifies a string to be added to the end of the AeDebug registry key. This command will display no message if it succeeds, but will display a failure message if it fails. When CDB is the postmortem debugger, it will be activated whenever an application crashes.
To change the postmortem debugger to NTSD, run ntsd -iae or ntsd -iaec KeyString… When the -iaec switch is used, KeyString specifies a string to be added to the end of the AeDebug registry key. If KeyString contains spaces, it must be enclosed in quotation marks. This command will display no message if it succeeds, but will display a failure message if it fails. When NTSD is the postmortem debugger, it will be activated whenever an application crashes.
To change the postmortem debugger back to Dr. Watson, run drwtsn32 -i. When Dr. Watson is the postmortem debugger, a memory dump file will be written to disk if an application crashes. See Dr. Watson Command-Line Options for details.
Only a system administrator can alter the postmortem settings.
If a postmortem debugger has been installed, you can deliberately break into the debugger from a user-mode application by calling the DebugBreak function.
?
like it has been stated several times earlier there is no better way other than do it yourself
and read and reread the windbg help file until things start making sense on your own
scott noone or for that matter anyone who is reading or responding to this list probably might? never need?to use usermode debugging
but they still?know it in back of thier mind??how to enable?or?disable user mode exception and they also post the os that this option works?
thats mainly because they?might have glanced over the help file quiet a few times just reading it like a novel??
try searching for noumex switch as an added trivia to the debugger handling user mode exceptions
regards
raj_r
On 11/17/08, Lin George wrote:
> Thanks for your advice, Martin!
>
> 1.
>
> Previously I think breakpoint is set by a debugger and breakpoint only effects if the binary is attached with debugger, if no debugger attached, no breakpoint will take effect. Is that true?
>
> 2.
>
> I am confused about what do you mean “any breakpoint that is not handled by a user mode debugger” – my confusion is, if the user mode debugger set the breakpoint, say break in main function, the user mode debugger should be able to handle this breakpoint (I think user mode debugger should be able to handle all breakpoints which is listed in bl command in Windbg). Could you show me a sample which user mode debugger sets a breakpoint, but not handle the breakpoint?
>
> 3.
>
> “there events in the os itself that cause breakpoints” – do you mean int 3 interruption from some software (the running software is not attached with user mode debugger but emit int 3 interruption, so the software is supposed to delegate kernel debugger to handle, and if no kernel debugger from host machie, the target machine is hang)? Or you mean something else?
>
> BTW: why I ask this question is I want to make it clear whether it is my program bug which causes system halt or just open kernel debugger issue which causes system halt.
>
> regards,
> George
>
>
> ----- Original Message ----
> From: Martin O’Brien
> To: Kernel Debugging Interest List
> Sent: Monday, November 17, 2008 9:10:27 PM
> Subject: Re:[windbg] kernel debugger option
>
> 1.??Yes - any breakpoint that is not handled by a user mode debugger will cause the target to ‘halt,’ because it is expecting a kernel debugger to be connected.??I haven’t any idea of what you’re talking about with the rest of that, but there events in the os itself that cause breakpoints, and there’s also third party software that behaves very differently with a configuration that enabled /debug support, so it’s not something that you can control, especially in the case of CHK builds.
>
> 2.??Read the documentation.??Please.??All you have to do is copy the existing line to a new line and modify it, but, again, read the documentation, please.
>
> Both of those being said, it doesn’t matter, given what you have experienced yourself:
>
> > Yes, Martin. I met with the machine halt problem as you mentioned, and I suspect it is kernel debugger option issue.
>
> Doesn’t this settle the question for you???Why does it matter if you can’t even boot without a debugger enabled, and no, it’s not an option problem, unless you mean not enabling debugging as the ‘option.’
>
> George, you need to understand that learning how to use windbg for kernel work takes a good three to six months to figure out, and that assumes that you know something about kernel work to begin with.???There are no tutorials for learning kd debugging, the documentation deeply, deeply sucks, and there is no way to learn it other than to just roll up your sleeves and do it.??You.??Not me.??Not Tim.??Not Skywing.??Not Snoone.??Not raj_r.??Not anyone else.??You.??This subject (how to use windbg for kd) is one of the most common questions on these lists, and because of that and that there is no answer other than ‘do it yourself,’ it’s also one of the questions for which members have the least patience.
>
> Do with this piece of advice what you will, but given what you have shown us to date, you don’t seem to be willing to figure things out on your own, and you also don’t generally like what we tell you, so I really, really, really don’t think you’re going to like this type of work.
>
>
> Good luck,
>
> mm
>
>
>
>
>
>
>
>
>
>
>
>
> Lin George wrote:
> > Yes, Martin. I met with the machine halt problem as you mentioned, and I suspect it is kernel debugger option issue.
> >
> > 1. You mentioned “most likely, depending on what else you have going on, like a user mode debugger” – my confusion is do you mean breakpoint makes machine halt? My confusion is break point only takes effect when there is some binary under debug (with debugger attached), and break point is hit. If I just reboot the machine and with the kernel debugger option turned on, no breakpoint should take effect, so I think break point will never makes machine halt. Please correct me if I am wrong.
> >
> > 2. “more than one option in the boot.ini” – you mean we can let user select from start whether boot with kernel debugger turned on or turned off? Looks like fancy.
> >
> > regards,
> > George
> >
> >
> > ----- Original Message ----
> > From: Martin O’Brien
> > To: Kernel Debugging Interest List
> > Sent: Monday, November 17, 2008 8:36:06 PM
> > Subject: Re:[windbg] kernel debugger option
> >
> > It’s been a while since I’ve used anything pre-bcd for a target, but if I recall correctly, it will probably not boot without a debugger connected, but even if it does, breakpoints (most likely, depending on what else you have going on, like a user mode debugger) and traps will cause the machine to halt, so I guess these would qualify as ‘strange.’
> >
> > You can and should always have more than one option in the boot.ini, so just add the debugger option, and leave the original one alone.
> >
> > Strictly speaking, a debugger connection is a security risk, but in practice, if someone can get that close to the machine, it’s all a waste of time, so it’s not something that I would worry about on that basis, but certainly there’s no upside to having it in production.
> >
> > Again George - cart before the horse???Why don’t you learn how to use the debugger first, and worry about this later.
> >
> >
> > Good luck,
> >
> > mm
> >
> > Lin George wrote:
> >> Hello everyone,
> >>
> >> I am turning on the kernel debugger option in boot.ini. But I am not sure whether I should remove the option if I do not debug the target machine? Whether keep the kernel debugger option in boot.ini will make the system unstable or behaves strangely sometimes?
> >>
> >> thanks in advance,
> >> George
> >>
> >>
> >>???
> >
> > —
> > You are currently subscribed to windbg as: xxxxx@yahoo.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
> >
> >
> >???
>
> —
> You are currently subscribed to windbg as: xxxxx@yahoo.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
>
> —
> You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
?— You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi S,
Your reply is short and I am trying to understand what you mean. Here is my understanding, is that what you mean below?
I enable kernel debugger option in boot.ini, but not connected at boot time, in this situation Windows could boot, but mark a flag to indicate the kernel debugger (from host) exist?
When there is unhandled exception, since the flag marks kernel debugger (host) as present, system will try to connect to the kernel debugger, but since no host kernel debugger there, system will halt?
regards,
George
----- Original Message ----
From: Skywing
To: Kernel Debugging Interest List
Sent: Tuesday, November 18, 2008 1:41:55 AM
Subject: RE: Re:[windbg] kernel debugger option
Note that you need to not have the debugger connected at boot time or it will be flagged as present, and thus things like kernel mode image loads will trigger blocking kd communication.
- S
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Monday, November 17, 2008 10:41 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] kernel debugger option
> 1.? Yes - any breakpoint that is not handled by a user mode debugger will
> cause the target to ‘halt,’ because it is expecting a kernel debugger to
> be connected.
You can actually control this behavior with kdbgctrl, which is handy if you
want to boot your workstation with /debug. Requires Server 2003 and later
though,
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“Martin O’Brien” wrote in message
news:xxxxx@windbg…
> 1.? Yes - any breakpoint that is not handled by a user mode debugger will
> cause the target to ‘halt,’ because it is expecting a kernel debugger to
> be connected.? I haven’t any idea of what you’re talking about with the
> rest of that, but there events in the os itself that cause breakpoints,
> and there’s also third party software that behaves very differently with a
> configuration that enabled /debug support, so it’s not something that you
> can control, especially in the case of CHK builds.
>
> 2.? Read the documentation.? Please.? All you have to do is copy the
> existing line to a new line and modify it, but, again, read the
> documentation, please.
>
> Both of those being said, it doesn’t matter, given what you have
> experienced yourself:
>
> > Yes, Martin. I met with the machine halt problem as you mentioned, and I
> > suspect it is kernel
> debugger option issue.
>
> Doesn’t this settle the question for you?? Why does it matter if you can’t
> even boot without a debugger enabled, and no, it’s not an option problem,
> unless you mean not enabling debugging as the ‘option.’
>
> George, you need to understand that learning how to use windbg for kernel
> work takes a good three to six months to figure out, and that assumes that
> you know something about kernel work to begin with. There are no tutorials
> for learning kd debugging, the documentation deeply, deeply sucks, and
> there is no way to learn it other than to just roll up your sleeves and do
> it.? You.? Not me.? Not Tim.? Not Skywing.? Not Snoone.? Not raj_r.? Not
> anyone else.? You.? This subject (how to use windbg for kd) is one of the
> most common questions on these lists, and because of that and that there
> is no answer other than ‘do it yourself,’ it’s also one of the questions
> for which members have the least patience.
>
> Do with this piece of advice what you will, but given what you have shown
> us to date, you don’t seem to be willing to figure things out on your own,
> and you also don’t generally like what we tell you, so I really, really,
> really don’t think you’re going to like this type of work.
>
>
> Good luck,
>
> mm
>
>
>
>
>
>
>
>
>
>
>
>
> Lin George wrote:
>> Yes, Martin. I met with the machine halt problem as you mentioned, and I
>> suspect it is kernel debugger option issue.
>>
>> 1. You mentioned “most likely, depending on what else you have going on,
>> like a user mode debugger” – my confusion is do you mean breakpoint
>> makes machine halt? My confusion is break point only takes effect when
>> there is some binary under debug (with debugger attached), and break
>> point is hit. If I just reboot the machine and with the kernel debugger
>> option turned on, no breakpoint should take effect, so I think break
>> point will never makes machine halt. Please correct me if I am wrong.
>>
>> 2. “more than one option in the boot.ini” – you mean we can let user
>> select from start whether boot with kernel debugger turned on or turned
>> off? Looks like fancy.
>>
>> regards,
>> George
>>
>>
>> ----- Original Message ----
>> From: Martin O’Brien
>> To: Kernel Debugging Interest List
>> Sent: Monday, November 17, 2008 8:36:06 PM
>> Subject: Re:[windbg] kernel debugger option
>>
>> It’s been a while since I’ve used anything pre-bcd for a target, but if I
>> recall correctly, it will probably not boot without a debugger connected,
>> but even if it does, breakpoints (most likely, depending on what else you
>> have going on, like a user mode debugger) and traps will cause the
>> machine to halt, so I guess these would qualify as ‘strange.’
>>
>> You can and should always have more than one option in the boot.ini, so
>> just add the debugger option, and leave the original one alone.
>>
>> Strictly speaking, a debugger connection is a security risk, but in
>> practice, if someone can get that close to the machine, it’s all a waste
>> of time, so it’s not something that I would worry about on that basis,
>> but certainly there’s no upside to having it in production.
>>
>> Again George - cart before the horse?? Why don’t you learn how to use the
>> debugger first, and worry about this later.
>>
>>
>> Good luck,
>>
>> mm
>>
>> Lin George wrote:
>>> Hello everyone,
>>>
>>> I am turning on the kernel debugger option in boot.ini. But I am not
>>> sure whether I should remove the option if I do not debug the target
>>> machine? Whether keep the kernel debugger option in boot.ini will make
>>> the system unstable or behaves strangely sometimes?
>>>
>>> thanks in advance,
>>> George
>>>
>>>
>>>
>>
>> —
>> You are currently subscribed to windbg as: xxxxx@yahoo.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>>
>
—
You are currently subscribed to windbg as: xxxxx@valhallalegends.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Lin George wrote:
In step 3, it is mentioned, “If no user-mode debugger is attached, and
Windows has an open kernel-debugging connection, and the error is a
breakpoint interrupt, Windows will attempt to contact the kernel
debugger.” – my situation is, I only turn on the kernel debugger
option in boot.ini, no actual kernel debugger host connected. In this
situation, does Windows treat it as there is an open kernel-debugging
connection and will wait forever for the non-existing debugger host to
connect – which causes machine hang?
Yes, exactly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Thanks Tim,
From my study of exception handling approach on Windows, I think unhandled exception from application will cause cause machine halt if there is (treated as) open kernel debugger connection?
Will some types of events also cause the same effect?
Why machine finally reboot in my experience?
regards,
George
----- Original Message ----
From: Tim Roberts
To: Kernel Debugging Interest List
Sent: Wednesday, November 19, 2008 1:22:22 AM
Subject: Re: [windbg] kernel debugger option
Lin George wrote:
>
>?
>
> In step 3, it is mentioned, “If no user-mode debugger is attached, and
> Windows has an open kernel-debugging connection, and the error is a
> breakpoint interrupt, Windows will attempt to contact the kernel
> debugger.” – my situation is, I only turn on the kernel debugger
> option in boot.ini, no actual kernel debugger host connected. In this
> situation, does Windows treat it as there is an open kernel-debugging
> connection and will wait forever for the non-existing debugger host to
> connect – which causes machine hang?
>
Yes, exactly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
—
You are currently subscribed to windbg as: xxxxx@yahoo.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Cool, PA!
> No, it will wait some time and then continue booting.
Are there any timeout settings? I tried to find in debugger document, but failed.
I mean, the kernel debugger “stub” of the debuggee still is in active state and behaves as if the machine is being debugged. If crash or breakpoint occurs, it will wait for debugger to connect, for indefinitely long (no timeout this time).
2.1?I have tried with unhandled exception case, looks like the whole OS is halt?
2.2?You mentioned if timeout machine will reboot before (in item 1 above), but currently you mentioned no timeout. Conflicting?
2.3?“the kernel debugger “stub” of the debuggee still is in active state” – actually I did not active the debuggee manually or explicitly. Do you mean if we boot the machine with kernel debugger option on in boot.ini, the debuggee will be inactive state automatically?
regards,
George
----- Original Message ----
From: Pavel A.
To: xxxxx@yahoo.com
Sent: Wednesday, November 19, 2008 3:13:35 AM
Subject: Re: [windbg] kernel debugger option
Replies inline.
–PA
On Tue, Nov 18, 2008 at 2:43 PM, Lin George wrote:
>
> Hi PA,
>
> You are good guy here.
>
> 1.
>
> “If you leave debugger options there, but the host debugger is not connected, Windows possibly will timeout and continue booting.”
>
> I am under pressure that other people say it is my bug. But I suspect it is kernel debugger issue – which cause machine halt/reboot.
Why these other people have enabled kernel debugger?
Are they debugging other programs or drivers?
Maybe they are right and it is your bug.
Kernel debugger by itself does not cause nasty things.
If “halt/reboot” occurs, have you or they tried to find out why?
( look at the dumps )
>So, you mean even if there is no breakpoint hit, if I enable kernel debugger in boot.ini, during start of the machine, it will wait for the connection from debugging host machine? If no debugging host machine connection comes in, the machine will reboot? Is that your point?
>
No, it will wait some time and then continue booting.
> I did search in Windbg help document but have not found your claims above, do you have any documents to support your statements?
No documents, just experience.
> 2.
>
> “But the debugger is still active. If the code hits a breakpoint, it will hang (wait for debugger) rather than crash.”
>
> I do not know what do you mean debugger is still active.
I mean, the kernel debugger “stub” of the debuggee still is in active state and behaves as if the machine is being debugged.
If crash or breakpoint occurs, it will wait for debugger to connect,
for indefinitely long (no timeout this time).
>I have never opened ntsd/kd/Windbg/Visual Studio on the machine, does
>it mean debugger will not be active and breakpoint hit issue (which
>cause machine hang) you mentioned above will never happen?
You don’t run windbg or kd on same machine, you run it on another machine.
Regards,
–PA
Lin George wrote:
From my study of exception handling approach on Windows, I think unhandled exception from application will cause cause machine halt if there is (treated as) open kernel debugger connection?
Yes. Well, it’s not really a “halt” – it is waiting for you to hook up
a debugger. As soon as you do so, it will display the exception and you
can continue to operate.
Will some types of events also cause the same effect?
Kernel faults, kernel breakpoints, and uncaught user-mode second chance
exceptions (including user-mode breakpoints). That’s it, as far as I know.
Why machine finally reboot in my experience?
That hasn’t been my experience, but perhaps I just wasn’t patient enough
to wait that long…
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.