Windbg: Disable user mode debugging
Armin Zingler
(before giving an update to my previous thread, one question:)
I configured a host and target computer to enable kernel mode debugging
via a null-modem cable. Works well. The only problem is: When I
start Visual Studio on the target machine, it says "Visual Studio has
detected that a kernel debugger is present...". It also says:
"The kernel debugger can be configured to allow debugging in Visual
Studio. Please see Help for further details."
I've searched the Help thoroughly but I didn't find how to do this. Do
they mean the "Event filters" dialog in Windbg that is running on the
host machine?
Or, is using the "/crashdebug" option in boot.ini (on the target
computer) the only way to get rid of the VS message?
Armin
Armin Zingler
> Or, is using the "/crashdebug" option in boot.ini (on the target
> computer) the only way to get rid of the VS message?
Ok, I found the boot.ini "/debug=noumex" switch. Sorry for bothering...
But, VS' message is still the same. In addition, the target machine
is really slow (mouse movements only every 5th second). So, there
is still the question how to start VS on the target machine without
this message and without slowdown.
Thanks!
Armin
Ivan Brugiolo [MSFT]
the managed-code debugging infrastructure was (poorly) designed.
Basically, the managed code debugging infrastructure requires
exeception reflection even when KD is active.
You would need to run `kdbgctrl.exe -eu`.
For the general slow-down of the machine, I cannot speculate.
I run all of my machines with KD enabled all the times, and,
there is no slowdown that I can see.
Maybe there is some debug-spew going on, and, writing to the serial port
is very slow.
--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Armin Zingler" <az.n...@freenet.de> wrote in message
news:uLuBvDxU...@TK2MSFTNGP04.phx.gbl...
Armin Zingler
"Ivan Brugiolo [MSFT]" <ivan...@online.microsoft.com> schrieb
> The warning given by Visual Studio is an artifact/consequence of the
> way the managed-code debugging infrastructure was (poorly) designed.
> Basically, the managed code debugging infrastructure requires
> exeception reflection even when KD is active.
> You would need to run `kdbgctrl.exe -eu`.
This "enables kernel debugger user exception handling".
I want to disable it. That's why I used "/debug=noumex" in boot.ini.
I want VS to handle user mode exceptions. Sorry if I wasn't clear
enough:
PC #1: a) BSOD machine b) boot.ini: "/debug=noumex" c) Runs VS (slowly)
I want to run VS here just like I always did. Without the
mentioned warning message and without slowing down the machine.
PC #2: runs Windbg (no problem here)
> For the general slow-down of the machine, I cannot speculate.
> I run all of my machines with KD enabled all the times, and,
> there is no slowdown that I can see.
> Maybe there is some debug-spew going on, and, writing to the serial
> port is very slow.
It is not a general slow-down. Only when VS is running, so the following
only applies after starting VS:
- Without "/debug=noumex": Windbg (on PC #2) frequently stops
at 80000003 exceptions. I can continue every time but it immediatelly
stops again.
- With "/debug=noumex": Windbg ignores 80000003 exceptions as intended.
But: slow-down of PC #1. I don't know why. Like you, I also guessed
that there is still (slow serial) data exchange, but I don't know why
and how to solve it.
I really wonder what they meant by saying "The kernel debugger can be
configured to allow debugging in Visual Studio". The kernel debugger is
Windbg on PC #2, but how to configure it...?
Armin
David Craig
in special kernel mode DLLs on the target system where boot.ini or the
bootcfg files reside. Windbg is NOT a kernel debugger, but a user mode
interface to the kernel debugger running on the target system. Use 1394a
with a TI chipset and the speed problem is mostly solved. SMP is always
slower than UP because the kernel debugger must marshal all the CPUs each
time it breaks. Single stepping is much slower on SMP than UP.
"Armin Zingler" <az.n...@freenet.de> wrote in message
news:ODka4rxU...@TK2MSFTNGP06.phx.gbl...
Armin Zingler
> This is really the wrong group for windbg.
Sorry, I did not even suspect there's an extra windbg group. Thanks.
But maybe it's not the right group, too (see below).
> However, the kernel
> debugger is in special kernel mode DLLs on the target system where
> boot.ini or the bootcfg files reside. Windbg is NOT a kernel
> debugger, but a user mode interface to the kernel debugger running
> on the target system.
I see.
> Use 1394a with a TI chipset and the speed
> problem is mostly solved.
I shouldn't have a speed problem with the current connection. That's
the point. I just want to run VS on the target computer. I don't
see why it slows the machine down because everything else I do
does not do it.
The problem is the combination VS+active kernel debugger. That's why
it is hard to limit the question to only one group. I don't think
m.p.windbg is the right place because it's only a problem on the
target machine where, as you wrote above, the "special kernel mode DLLs"
reside and where also VS runs.
I've already asked in the (German) VS group meanwhile, but I also
think that this group is the right one because of the "kernel debugging"
component. (I didn't find another "kernel" group @ m.p)
> SMP is always slower than UP because the
> kernel debugger must marshal all the CPUs each time it breaks. Single
> stepping is much slower on SMP than UP.
Ok
BTW, kdbgctrl.exe (on the target machine) always tells me:
"Unable to get Kernel debugger user exception enable, NTSTATUS
0xC0000003"
Don't worry, I'll handle it....
Armin
David Craig
subsystem meaning 32-bit Windows. The native system upon which the win32
subsystem runs is the place where the kernel debugger runs. You can have a
Unix subsystem also run and a win16 subsystem until Vista.
The slowness is expected since you have two debuggers trying to control the
machine and getting in each other's way. I don't try and do both at the
same time since I don't usually write any application code, but there may be
some way to do it. Maybe the VS newsgroup or either of the windbg
newsgroups can help. I know the windbg group has people from Microsoft
answering questions.
"Armin Zingler" <az.n...@freenet.de> wrote in message
news:uYMizwyU...@TK2MSFTNGP02.phx.gbl...
Armin Zingler
> This group is not applicable because of the win32 in the title. Win32
> is a subsystem meaning 32-bit Windows.
I don't have 64-bit Windows.
> The native system upon which
> the win32 subsystem runs is the place where the kernel debugger runs.
> You can have a Unix subsystem also run and a win16 subsystem until
> Vista.
Sorry, I don't understand the distinction made. The Win32 groups have
always been there for "native" Win32 programming. Maybe /this/ group is
for "programming" only, but debugging is also a part of it. Again,
there is no other "kernel" group.
> The slowness is expected since you have two debuggers trying to
> control the machine and getting in each other's way.
Maybe, but why? One is for user mode, the other for kernel. That's why
there must not be a conflict. The slowness is due to data exchange
between the machines (verified by varying serial port speed). There is
no reason for this massive transfer because debugging a user mode
application has nothing to do with the other machine that is
/only/ there for kernel debugging, so why transfer anything?
It's a local matter and nothing else.
> I don't try and do both at the same time since I don't usually write
> any application code, but there may be some way to do it. Maybe the
> VS newsgroup or either of the windbg newsgroups can help. I know the
> windbg group has people from Microsoft answering questions.
Windbg is just the UI, as you say. The problem is /only/ on the target
machine where the internal kernel debugger and VS seem to have a
conflict that mustn't be there. It has nothing to do with Windbg on the
other machine.
Why should I ask in a VStudio group (though I did)? Do you think they
deal a lot with kernel debugging?
This is the message I get in VS 2003:
http://msdn2.microsoft.com/en-us/library/cysxtck9(VS.80).aspx
Look at the fixes: suggestion 1 and 2 say "use the one OR the other"
Suggestion 3 "In the Kernel Debugger, disable user-mode exceptions."
should work. That's what I've already done! I did disable user-mode
exceptions in the kernel-debugger! Still it does not work. That's
the problem.
Armin Zingler
> This is the message I get in VS 2003:
> http://msdn2.microsoft.com/en-us/library/cysxtck9(VS.80).aspx
>
> Look at the fixes: suggestion 1 and 2 say "use the one OR the other"
> Suggestion 3 "In the Kernel Debugger, disable user-mode exceptions."
> should work. That's what I've already done! I did disable user-mode
> exceptions in the kernel-debugger! Still it does not work. That's
> the problem.
It looks as if I have to accept that both, managed debugging and kernel
debugging at the same time is not possible.
Anyways, that's probably mainly a VS/Framework problem, so sorry for
bothering anyone here.
Thanks.
Armin
Armin Zingler
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=206737
Unfortunately, kdbgctrl.exe doesn't work here (as mentioned: "Unable to
disable kernel debugger, NTSTATUS 0xC0000003"). Hmm....
Armin
David Craig
> "David Craig" <dri...@nowhere.us> schrieb
>> This group is not applicable because of the win32 in the title. Win32
>> is a subsystem meaning 32-bit Windows.
>
> I don't have 64-bit Windows.
>
NT or some other magical derivative from Dave Cutler. It does not do
Windows. It has no user interface components. Win32 is subsystem that does
video, mouse, and keyboard, plus a few other things via kernel32.dll and
win32k.sys (plus others). The kernel debugger is an extension to ntoskrnl
and maybe the hal too. Device drivers, other than video, cannot call
routines in win32k.sys. Device drivers use exports from ntoskrnl, hal, and
other device drivers.
>> The native system upon which
>> the win32 subsystem runs is the place where the kernel debugger runs.
>> You can have a Unix subsystem also run and a win16 subsystem until
>> Vista.
>
> Sorry, I don't understand the distinction made. The Win32 groups have
> always been there for "native" Win32 programming. Maybe /this/ group is
> for "programming" only, but debugging is also a part of it. Again,
> there is no other "kernel" group.
>
The use of 'kernel' for both places is a bad usage of the word. Try windbg
newsgroup and maybe the development.device.drivers newsgroup where you may
find some assistance. The Visual Studio newsgroups are probably more
closely related, but very few people do both types of debugging at the same
time. It just doesn't work well. If you have a device driver, just stub
out all user requests with an error. Run your user mode app and make sure
you see the correct parameters showing up in the call. After it appears to
work well, then debug the device driver. Finally, go back and make sure the
app handles the returned data correctly. Hard to both at the same time
especially if you get into that mangled code stuff.
>> The slowness is expected since you have two debuggers trying to
>> control the machine and getting in each other's way.
>
> Maybe, but why? One is for user mode, the other for kernel. That's why
> there must not be a conflict. The slowness is due to data exchange
> between the machines (verified by varying serial port speed). There is
> no reason for this massive transfer because debugging a user mode
> application has nothing to do with the other machine that is
> /only/ there for kernel debugging, so why transfer anything?
> It's a local matter and nothing else.
>
All breakpoints and other debugger support is done in the real kernel and
not the Win32 subsystem. When you have two debuggers something has to
decide who gets called.
>
>> I don't try and do both at the same time since I don't usually write
>> any application code, but there may be some way to do it. Maybe the
>> VS newsgroup or either of the windbg newsgroups can help. I know the
>> windbg group has people from Microsoft answering questions.
>
> Windbg is just the UI, as you say. The problem is /only/ on the target
> machine where the internal kernel debugger and VS seem to have a
> conflict that mustn't be there. It has nothing to do with Windbg on the
> other machine.
>
The confict cannot help but be there. The CPU only issues one interrupt.
Kernel mode components (NT) have to handle those interrupts and decide if
the system should blue screen, the process should be terminated, or a
debugger should get a chance to handle it.
Jochen Kalmbach [MVP]
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=206737
>
> Unfortunately, kdbgctrl.exe doesn't work here (as mentioned: "Unable to
> disable kernel debugger, NTSTATUS 0xC0000003"). Hmm....
XP ? Try on Vista ;)
--
Greetings
Jochen
My blog about Win32 and .NET
http://blog.kalmbachnet.de/
Armin Zingler
> Hi Armin!
>
> > http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=206737
> >
> > Unfortunately, kdbgctrl.exe doesn't work here (as mentioned:
> > "Unable to disable kernel debugger, NTSTATUS 0xC0000003"). Hmm....
>
> XP ? Try on Vista ;)
*argh* "..Windows Server 2003 or a later version.." Right. Dankeschön!
:)
Armin
Armin Zingler
>
> "Armin Zingler" <az.n...@freenet.de> wrote in message
> news:%23nXh6Jz...@TK2MSFTNGP03.phx.gbl...
> > "David Craig" <dri...@nowhere.us> schrieb
> > > This group is not applicable because of the win32 in the title.
> > > Win32 is a subsystem meaning 32-bit Windows.
> >
> > I don't have 64-bit Windows.
> >
> So you don't have 64-bit Windows. The native system is NOT Windows.
> It is NT or some other magical derivative from Dave Cutler. It
> does not do Windows. It has no user interface components. Win32 is
> subsystem that does video, mouse, and keyboard, plus a few other
> things via kernel32.dll and win32k.sys (plus others). The kernel
> debugger is an extension to ntoskrnl and maybe the hal too. Device
> drivers, other than video, cannot call routines in win32k.sys. Device
> drivers use exports from ntoskrnl, hal, and other device
> drivers.
I have no doubts about this, however, I think this is hairsplitting
in view of the actual problem. I do know that the kernel does not have
a UI, but you were the one who wrote "32-bit Windows". I was only
talking about finding the right group. I could also say that
the whole product is "Windows" even if some parts will never be
seen as windows on the screen. Nevertheless, no need to elaborate
on this deeper, ok? :-)
> > > The native system upon which
> > > the win32 subsystem runs is the place where the kernel debugger
> > > runs. You can have a Unix subsystem also run and a win16
> > > subsystem until Vista.
> >
> > Sorry, I don't understand the distinction made. The Win32 groups
> > have always been there for "native" Win32 programming. Maybe
> > /this/ group is for "programming" only, but debugging is also a
> > part of it. Again, there is no other "kernel" group.
> >
> The use of 'kernel' for both places is a bad usage of the word.
? I don't understand you. Neither did I choose the name for /this/
group, and as such, nor is it wrong to post to this group because
it is a problem with using the kernel debug engine. Yes, /now/ I know
that is in particular a VS problem - maybe caused by the kernel
implementation when handling both debuggers at a tim - but I wasn't
aware of this when I started the thread. Sometimes this turns out
afterwards.
> Try windbg newsgroup
No, they would send my away just like you do. The problem is there
even if Windbg does not run. But again, /now/ I know where the
problem is.
> and maybe the development.device.drivers newsgroup
I don't want to develop device drivers.
> where you may find some assistance. The Visual Studio newsgroups
> are probably more closely related, but very few people do both types
> of debugging at the same time.
Yes, like I said, I guess most people won't know anything about kernel
debugging at all there.
> It just doesn't work well. If you
> have a device driver, just stub out all user requests with an error.
> Run your user mode app and make sure you see the correct parameters
> showing up in the call. After it appears to work well, then debug
> the device driver. Finally, go back and make sure the app handles
> the returned data correctly. Hard to both at the same time
> especially if you get into that mangled code stuff.
I don't know how this relates to the situation described. Again,
the kernel debugger will be active all the time because it is
"waiting" for a BSOD. In addition, it is a (user mode) development
machine writing managed .Net applications. I do /not/ actively
do "mixed" debugging all the time. I actively only write managed
applications. Only as soon as a BSOD will occur, maybe tomorrow
or maybe in four weeks, I will turn to my other machine and
use Windbg to analyze the BSOD problem.
> > > The slowness is expected since you have two debuggers trying to
> > > control the machine and getting in each other's way.
> >
> > Maybe, but why? One is for user mode, the other for kernel. That's
> > why there must not be a conflict. The slowness is due to data
> > exchange between the machines (verified by varying serial port
> > speed). There is no reason for this massive transfer because
> > debugging a user mode
> > application has nothing to do with the other machine that is
> > /only/ there for kernel debugging, so why transfer anything?
> > It's a local matter and nothing else.
> >
> All breakpoints and other debugger support is done in the real
> kernel and not the Win32 subsystem. When you have two debuggers
> something has to decide who gets called.
Yes, but obviously this doesn't work well. Otherwise it wouldn't
communicate over the serial connection for local-only issues.
Again, "/debug=noumex" has been used.
> > > I don't try and do both at the same time since I don't usually
> > > write any application code, but there may be some way to do it.
> > > Maybe the VS newsgroup or either of the windbg newsgroups can
> > > help. I know the windbg group has people from Microsoft
> > > answering questions.
> >
> > Windbg is just the UI, as you say. The problem is /only/ on the
> > target machine where the internal kernel debugger and VS seem to
> > have a
> > conflict that mustn't be there. It has nothing to do with Windbg
> > on the other machine.
> >
> The confict cannot help but be there. The CPU only issues one
> interrupt. Kernel mode components (NT) have to handle those
> interrupts and decide if the system should blue screen, the process
> should be terminated, or a debugger should get a chance to handle
> it.
Ok, I will have to accept it.
Anyways, thanks for your participation! I consider this thread closed
now. ;)
Armin
Ben Voigt [C++ MVP]
[snip]
> I don't want to develop device drivers.
Then why do you have kernel debugging enabled? Ah, yes, you have a BSOD
problem. So you do want to debug device drivers, and debugging is one of
the many stages of development discussed on the development.device.drivers
ng.
>
>> where you may find some assistance. The Visual Studio newsgroups
>> are probably more closely related, but very few people do both types
>> of debugging at the same time.
>
> Yes, like I said, I guess most people won't know anything about kernel
> debugging at all there.
That's the truth.
>
>> It just doesn't work well. If you
>> have a device driver, just stub out all user requests with an error.
>> Run your user mode app and make sure you see the correct parameters
>> showing up in the call. After it appears to work well, then debug
>> the device driver. Finally, go back and make sure the app handles
>> the returned data correctly. Hard to both at the same time
>> especially if you get into that mangled code stuff.
>
> I don't know how this relates to the situation described. Again,
> the kernel debugger will be active all the time because it is
> "waiting" for a BSOD. In addition, it is a (user mode) development
> machine writing managed .Net applications. I do /not/ actively
> do "mixed" debugging all the time. I actively only write managed
> applications. Only as soon as a BSOD will occur, maybe tomorrow
> or maybe in four weeks, I will turn to my other machine and
> use Windbg to analyze the BSOD problem.
"mixed" debugging in .NET is not kernel and user...
"native" is overloaded:
.NET programmers talk about managed (MSIL) and native (machine code)
libraries.
What this group is distinguishing between is the Win32 API and the native
ntoskrnl API.
code written for Win32 API compiled to native machine code vs code written
for native API -- totally not the same thing
Armin Zingler
>
> "Armin Zingler" <az.n...@freenet.de> wrote in message
> news:ej$4kM5UI...@TK2MSFTNGP04.phx.gbl...
> [snip]
> > I don't want to develop device drivers.
>
> Then why do you have kernel debugging enabled? Ah, yes, you have a
> BSOD problem. So you do want to debug device drivers, and debugging
> is one of the many stages of development discussed on the
> development.device.drivers ng.
Last time: I always choose a group with care, however I'm not
perfect. As an application developer, everything that is not a
VB.Net or .Net Framework issue and goes deeper, is considered
"native Win32" (watch the double quotes) programming, like
doing API calls. That's why m.p.win32.programmer has always been
the right place. If that's not true, then I was wrong in the past
10 years. In addition, the current issue goes even deeper, into the
kernel. Therefore the subordinate group m.p.w32.p.kernel was obviously
the correct group. Is this really so absurd? I don't think so.
Anyways, no need to discuss this further, IMO.
> > > It just doesn't work well. If you
> > > have a device driver, just stub out all user requests with an
> > > error. Run your user mode app and make sure you see the correct
> > > parameters showing up in the call. After it appears to work
> > > well, then debug the device driver. Finally, go back and make
> > > sure the app handles the returned data correctly. Hard to both
> > > at the same time
> > > especially if you get into that mangled code stuff.
> >
> > I don't know how this relates to the situation described. Again,
> > the kernel debugger will be active all the time because it is
> > "waiting" for a BSOD. In addition, it is a (user mode) development
> > machine writing managed .Net applications. I do /not/ actively
> > do "mixed" debugging all the time. I actively only write managed
> > applications. Only as soon as a BSOD will occur, maybe tomorrow
> > or maybe in four weeks, I will turn to my other machine and
> > use Windbg to analyze the BSOD problem.
>
> "mixed" debugging in .NET is not kernel and user...
You see the double quotes around? As you have followed the thread, you
should know that we were talking about kernel debugging and application
level debugging. Therefore it is pretty obvious in the context of the
thread, moreover in the quoted paragraph what "mixed" meant in this
context. Sorry if it was still ambiguous for you.
Thanks.
Armin