Re: Windbg: Disable user mode debugging


"Armin Zingler" <az.nospam@xxxxxxxxxx> wrote in message
news:%23nXh6JzUIHA.3400@xxxxxxxxxxxxxxxxxxxxxxx
"David Craig" <drivers@xxxxxxxxxx> 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.

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.

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


"Armin Zingler" <az.nospam@xxxxxxxxxx> wrote in message
news:uYMizwyUIHA.5132@xxxxxxxxxxxxxxxxxxxxxxx
"David Craig" <drivers@xxxxxxxxxx> schrieb
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

"Armin Zingler" <az.nospam@xxxxxxxxxx> wrote in message
news:ODka4rxUIHA.5816@xxxxxxxxxxxxxxxxxxxxxxx
Ivan, thanks again for your fast response.

"Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx> 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


--

--
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.nospam@xxxxxxxxxx> wrote in message
news:uLuBvDxUIHA.4196@xxxxxxxxxxxxxxxxxxxxxxx
"Armin Zingler" <az.nospam@xxxxxxxxxx> schrieb
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











.

Relevant Pages

  • Re: kernel debug doesnt work,why?
    ... Dave Peverley wrote: ... target device,debug information always is "Kernel debugger is waiting to ...
    (microsoft.public.windowsce.platbuilder)
  • Re: difference between kernel debugger and KITL
    ... KITL is just the transport layer, and is used by more than just the ... Kernel Debugger that runs over it. ... you can get all the debug messages over KITL so it ... If kernel debugger requires KITL and would not work without KITL anyway, ...
    (microsoft.public.windowsce.platbuilder)
  • Windows CE 6.0 - USB Host Driver ohcd.dll Loading Issues
    ... PB Debugger The Kernel Debugger has been disconnected successfully. ... 2360 PID:400002 TID:410002 Initializing Memory Mapped File Support ...
    (microsoft.public.windowsce.platbuilder)
  • Re: serial connection to x86 cepc device
    ... PB Debugger Warning: Debugger service map is set to none. ... PB Debugger Debugger could not initialize connection. ... PB Debugger The Kernel Debugger is waiting to connect with target. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Platform Builder 5.0 and Windows Vista: Question on Kernel Debugge
    ... Do you have the debugger option set to KDStub in your TargetConnectivity box ... Currently I'm trying to get the kernel debugger running. ... PID:0 TID:0 Windows CE KernelInit ...
    (microsoft.public.windowsce.platbuilder)
Quantcast