Re: Windbg: Disable user mode debugging

"David Craig" <drivers@xxxxxxxxxx> schrieb

"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.

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

.

Relevant Pages

  • Re: Random reboots
    ... Disable automatic restart on system failure. ... Microsoft Windows Debugger Version 6.9.0003.113 X86 ... Mini Kernel Dump File: Only registers and stack trace are available ...
    (microsoft.public.windowsxp.help_and_support)
  • Random reboot
    ... Microsoft Windows Debugger Version 6.3.0005.1 ... Copyright Microsoft Corporation. ... Windows XP Kernel Version 2600 UP Free ... If a kernel debugger is available get the stack backtrace. ...
    (microsoft.public.windowsxp.hardware)
  • Re: Windows debugging/vulnerability analysis
    ... I am looking for some resources on analyzing vulnerabilities in Windows ... drivers and/or the kernel. ... Windows debugger capabable of debugging kernel-based code. ... The NSA has designated Norwich University a center of Academic Excellence in Information Security. ...
    (Security-Basics)
  • Re: Just to know: system calls on windows...
    ... POSIX and the kernel are on separate levels. ... Because Microsoft is the only maintainer of the Windows kernel, they don't need to give anyone else access, so the kernel is fairly self-contained. ... You are not supposed to call NTDLL.DLL from your code either, but instead one of the subsystems (like Win32). ...
    (comp.lang.asm.x86)
  • Re: [9fans] vmware 5.0
    ... inside windows could also be used to make Xen in Windows possible. ... it to allow domU's to be run on top of win32 (or the NT kernel, or any other kernel, for that matter). ... If you didn't want to interpret the cpu instructions you would need a little hook in the native kernel to catch trap instructions and handle page faults. ...
    (comp.os.plan9)