Kernel Debugging over Network

NTDEV
1

Hi,

I am trying to do KMDF driver debugging over network using visual studio. Both the host and target machines are using Windows 8.1 (64 bit) OS and WDK 8.1 with update. I set up the debug environment over network via visual studio ultimate 13. I built the KMFD Hello World Driver (http://msdn.microsoft.com/en-us/library/windows/hardware/hh439665) and deployed it to the target machine via visual studio successfully.

However, I cannot do the debugging. I don’t see any ‘kd command prompt’ as mentioned in the link above and cannot ‘Break All’ also. Also tried inserting breakpoint at particular functions.

Can anyone please help me in this regards. Thanks.

2

Debug the target machine from a second visual studio instance.

Click the “Debug” menu and choose the “Attach to process…” menu item.
Then set “Transport” to “Windows Kernel Mode Debugger” and “Qualifier”
to the name of the target machine. The target machine name should be present
because you have already configured deployement.

You should only build and deploy from your first Visual Studio instance
because building and deploying stops the debugging session.

You could also use WinDbg rather than a second instance of Visual Studio.

3

Even given what Mr. Geek says to the contrary… abandon using WinDbg within the debugger. You will be happier in the long run.

Rather, run WinDbg separately.

http:

You’ll have the whole thing setup and working in minutes, without the complications of having VS to deal with.

Peter
OSR
@OSRDrivers</http:>

4

Thanks to both of you. I found in a MSDN document that the target should not have visual studio and WDK installed. So I (i) removed both the VS and WDK from the target and also the provision, (ii) ran the ‘WDK Test Target Setup’ (got from the WDK installation of the host) at the target, (iii) provisioned the target again. Now I can see the ‘kd’ command prompt and run commands like, lm, etc. mentioned here (http://msdn.microsoft.com/en-us/library/windows/hardware/hh439665(v=vs.85).aspx). However, as soon as I give ‘break all’ command, a new tab opens in the editor saying “Frame not in Module - The current stack frame was not found in a loaded module. Source cannot be shown for this location”. At the same time, the target machine hangs. Can you please give me any clue?

@Peter: I am just learning the kernel debugging. This time I could connect to the target using Windbg. Can you please tell me what should I set for executable path, image path or symbol path? How should I perform debugging for the particular ‘HelloWorldDriver’ that I am working with? Sorry for the na?ve question.

Thanks.

5

xxxxx@gmail.com wrote:

Thanks to both of you. I found in a MSDN document that the target should not have visual studio and WDK installed.

That’s not true. The target does not NEED Visual Studio nor the WDK,
but there’s no harm in having them.

However, as soon as I give ‘break all’ command, a new tab opens in the editor saying “Frame not in Module - The current stack frame was not found in a loaded module. Source cannot be shown for this location”.

What do you mean by “break all” command? If you just “broke in” at a
random location, then the comment is quite correct. The CPU is
executing within the kernel, and you don’t have symbols or source for
that. You could have seen the disassembly or looked at the registers,
and you could have resumed the system by pressing F5 or giving the “g”
command.

@Peter: I am just learning the kernel debugging. This time I could connect to the target using Windbg. Can you please tell me what should I set for executable path, image path or symbol path? How should I perform debugging for the particular ‘HelloWorldDriver’ that I am working with?

The symbol path needs to be a spot on your disk where the debugger can
cache the symbols it downloads from Microsoft’s symbol server, plus
special text giving the URL of the symbol server. For example:
srv*c:\symbols*http://msdl.microsoft.com/download/symbols

You don’t need an executable path, because you aren’t debugging an
executable.

Have you actually installed your driver on the target box?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

6

Hi Tim,

I followed the exact steps mentioned here
http://msdn.microsoft.com/en-us/library/windows/hardware/hh439665(v=vs.85).aspx

It instructs to - ‘9.On the Debug menu, choose Break All. The debugger on the host computer will break into the target computer. In the Debugger Immediate window, you can see the kernel debugging command prompt: kd>.’

The driver has been installed in the target. I see successful deployment message at the host (via VS) and the driver from the device manager at the target. I cannot figure out how to debug :frowning:

Thanks.

7

>The driver has been installed in the target. I see successful deployment message at the host (via VS) and the driver from the device manager at the target. I cannot figure out how to debug :frowning:

Add the following code to the start of the functions you want to debug, then redeploy the driver.

if (KD_DEBUGGER_NOT_PRESENT == FALSE)
{
// A kernel debugger is active.
DbgBreakPoint();
}

8

xxxxx@gmail.com wrote:

I followed the exact steps mentioned here
http://msdn.microsoft.com/en-us/library/windows/hardware/hh439665(v=vs.85).aspx

It instructs to - ‘9.On the Debug menu, choose Break All. The debugger on the host computer will break into the target computer. In the Debugger Immediate window, you can see the kernel debugging command prompt: kd>.’

Ah. I have not used WinDbg from within VS, so I didn’t know what the
menu item was named. My guess is that it did exactly what you asked: it
froze the system and was waiting for you to do something. It couldn’t
display any source code, because you don’t have symbols or source for
the kernel. If you had looked at the disassembly or the registers, you
would have seen good info.

The driver has been installed in the target. I see successful deployment message at the host (via VS) and the driver from the device manager at the target. I cannot figure out how to debug :frowning:

It’s actually rather similar to the way you would debug an application,
if you attached the debugger in the middle of a run. In order to catch
your driver in action, you have to set a breakpoint somewhere that your
driver will execute. You could, for example, set a breakpoint at your
AddDevice routine, and then disable and re-enable the device in Device
Manager. That forces the initialization to happen again.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

9

>as soon as I give ‘break all’ command, a new tab opens in the editor saying "Frame not in Module -

After you have successfully got a “kd>” prompt, the next step is to ensure that the correct symbols are loaded.

.symfix command will set up your debugger to auto-download the Windows symbols from MS. For this, you need to create the empty the symbol cache directory, and provide it to .symfix.

To ensure everything is OK, say “lm” or “lmv”. For the first time, it runs slowly, since it downloads lots of PDBs from MS to the symbol cache directory.

In “lm” output, MS’s modules must have PDB symbols with them, and so must be your driver.

Then say “x MyDriver!*”, and ensure that your function names are printed.

Then try breakpoints.

Say “bp MyDriver!MyFunction”, then F5, go to target machine and execute the code path there which must hit MyDriver!MyFunction.

You will see the target frozen, and the debugger stopped on a kd> prompt.

To dump the layout of your data structures, use “dt _MY_STRUCTURE_TYPE”. To dump the structure with values, either use “dt StructVar” if the debugger knows the name of “StructVar”, or “dt NumericAddress _MY_STRUCTURE_TYPE”.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

10

> if (KD_DEBUGGER_NOT_PRESENT == FALSE)

Never, ever, compare booleans with TRUE and FALSE.

“Introduction to programming” for schoolchildren.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

11

You’re going to have to break that one down for me Barney-style, Mr. Shatskih. Cuz while I think Mr. Geek’s advice is terrible, If I wanted to know if the debugger were present that’s how I could code it.

Peter
OSR
@OSRDrivers

12

>> if (KD_DEBUGGER_NOT_PRESENT == FALSE)

Never, ever, compare booleans with TRUE and FALSE.

“Introduction to programming” for schoolchildren.
[/quote]

You’re going to have to break that one down for me Barney-style, Mr. Shatskih. Cuz while I think Mr. Geek’s advice is terrible, If I wanted to know if the debugger were present that’s how I could code it.

Yes. Just do it this way:

if (!KD_DEBUGGER_NOT_PRESENT)
…

:slight_smile:

–
Maxim S. Shatskih

Microsoft MVP on File System And Storage

xxxxx@storagecraft.com

http://www.storagecraft.com

13

I watched a very good (actually brilliant) Windows Kernel developer struggle for a day or more with code that simply was not doing what he had expected. It was something like:

if ( some_variable == TRUE )…

It would never perform the target of the “if” statement even though some_variable was non-zero. As it turns out, the value of some-variable was 3, instead of TRUE (1). I’ve even seen some (very) bad coding style guidelines that actually say to do an explicit comparison to “true” or “false” as being somehow more readable than just using the expression and/or the NOT (!) operator!

I only wish Microsoft had used a bit variable instead of a LONG in its broken BOOLEAN implementation (or is it DWORD, which is kinda like a LONG but unsigned…or is it signed? oh well). It would have surely made these things much less of a problem.

Greg

— xxxxx@storagecraft.com wrote:

From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Subject: Re:[ntdev] Kernel Debugging over Network
Date: Wed, 3 Dec 2014 18:40:45 +0300

>> if (KD_DEBUGGER_NOT_PRESENT == FALSE)
>
> Never, ever, compare booleans with TRUE and FALSE.
>
> “Introduction to programming” for schoolchildren.
>
[/quote]

>
> You’re going to have to break that one down for me Barney-style, Mr. Shatskih. Cuz while I think Mr. Geek’s advice is terrible, If I wanted to know if the debugger were present that’s how I could code it.

Yes. Just do it this way:

if (!KD_DEBUGGER_NOT_PRESENT)
…

:slight_smile:

–
Maxim S. Shatskih

Microsoft MVP on File System And Storage

xxxxx@storagecraft.com

http://www.storagecraft.com

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

14

The broken implementation of BOOLEAN heralds from the earliest releases of
the MSFT C compiler and the earliest implementations of windows. One of the
things MSFT continues to get right is not breaking existing code with each
release of the OS or compiler. See for example Linux for how to get this
wrong.

Mark Roddy

On Wed, Dec 3, 2014 at 10:50 AM, Gregory G Dyess wrote:

>
> I watched a very good (actually brilliant) Windows Kernel developer
> struggle for a day or more with code that simply was not doing what he had
> expected. It was something like:
>
> if ( some_variable == TRUE )…
>
> It would never perform the target of the “if” statement even though
> some_variable was non-zero. As it turns out, the value of some-variable
> was 3, instead of TRUE (1). I’ve even seen some (very) bad coding style
> guidelines that actually say to do an explicit comparison to “true” or
> “false” as being somehow more readable than just using the expression
> and/or the NOT (!) operator!
>
> I only wish Microsoft had used a bit variable instead of a LONG in its
> broken BOOLEAN implementation (or is it DWORD, which is kinda like a LONG
> but unsigned…or is it signed? oh well). It would have surely made these
> things much less of a problem.
>
> Greg
>
>
> — xxxxx@storagecraft.com wrote:
>
> From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
> Subject: Re:[ntdev] Kernel Debugging over Network
> Date: Wed, 3 Dec 2014 18:40:45 +0300
>
> >> if (KD_DEBUGGER_NOT_PRESENT == FALSE)
> >
> > Never, ever, compare booleans with TRUE and FALSE.
> >
> > “Introduction to programming” for schoolchildren.
> >
[/quote]

> >
> > You’re going to have to break that one down for me Barney-style, Mr.
> Shatskih. Cuz while I think Mr. Geek’s advice is terrible, If I wanted to
> know if the debugger were present that’s how I could code it.
>
> Yes. Just do it this way:
>
> if (!KD_DEBUGGER_NOT_PRESENT)
> …
>
> :slight_smile:
>
> –
> Maxim S. Shatskih
>
> Microsoft MVP on File System And Storage
>
> xxxxx@storagecraft.com
>
> http://www.storagecraft.com
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

15

I would not call it a broken implementation by Microsoft. I first encountered that bug in the Unix kernel in the mid-70’s. Blame Kernighan and Ritchie not all the compiler types who came afterward.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Mark Roddy
Sent: Wednesday, December 03, 2014 11:45 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Kernel Debugging over Network

The broken implementation of BOOLEAN heralds from the earliest releases of the MSFT C compiler and the earliest implementations of windows. One of the things MSFT continues to get right is not breaking existing code with each release of the OS or compiler. See for example Linux for how to get this wrong.

Mark Roddy

On Wed, Dec 3, 2014 at 10:50 AM, Gregory G Dyess wrote:

I watched a very good (actually brilliant) Windows Kernel developer struggle for a day or more with code that simply was not doing what he had expected. It was something like:

if ( some_variable == TRUE )…

It would never perform the target of the “if” statement even though some_variable was non-zero. As it turns out, the value of some-variable was 3, instead of TRUE (1). I’ve even seen some (very) bad coding style guidelines that actually say to do an explicit comparison to “true” or “false” as being somehow more readable than just using the expression and/or the NOT (!) operator!

I only wish Microsoft had used a bit variable instead of a LONG in its broken BOOLEAN implementation (or is it DWORD, which is kinda like a LONG but unsigned…or is it signed? oh well). It would have surely made these things much less of a problem.

Greg

— xxxxx@storagecraft.com wrote:

From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Subject: Re:[ntdev] Kernel Debugging over Network
Date: Wed, 3 Dec 2014 18:40:45 +0300

>> if (KD_DEBUGGER_NOT_PRESENT == FALSE)
>
> Never, ever, compare booleans with TRUE and FALSE.
>
> “Introduction to programming” for schoolchildren.
>
[/quote]

>
> You’re going to have to break that one down for me Barney-style, Mr. Shatskih. Cuz while I think Mr. Geek’s advice is terrible, If I wanted to know if the debugger were present that’s how I could code it.

Yes. Just do it this way:

if (!KD_DEBUGGER_NOT_PRESENT)
…

:slight_smile:

–
Maxim S. Shatskih

Microsoft MVP on File System And Storage

xxxxx@storagecraft.com

http://www.storagecraft.com

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

— NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See http://www.osr.com/careers For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

16

Agreed. Continuing broken-ness is often better than fixing the implementation but breaking tons of code built upon the broken-ness.

Sometimes, it’s not quite so clear. For example the brain-damaged Window function’s signature of LParam/WParam parameters as opposed to X-Windows much better pointer to an event structure mechanism. When NT came out, that could have been fixed as opposed to making the strange decision of just making WParam into a long and keeping the name WParam. It made porting 16 bit code easier, but at the cost of now decades of new Windows programmers scratching their heads and wondering what was in the coffee or smoke those guys were using.

My comment was just lamenting the original broken BOOLEAN design, not that they kept compatibility.

Greg

— xxxxx@hollistech.com wrote:

From: Mark Roddy
To: “Windows System Software Devs Interest List”
Subject: Re: [ntdev] Kernel Debugging over Network
Date: Wed, 3 Dec 2014 11:44:36 -0500

The broken implementation of BOOLEAN heralds from the earliest releases of
the MSFT C compiler and the earliest implementations of windows. One of the
things MSFT continues to get right is not breaking existing code with each
release of the OS or compiler. See for example Linux for how to get this
wrong.

Mark Roddy

On Wed, Dec 3, 2014 at 10:50 AM, Gregory G Dyess wrote:

>
> I watched a very good (actually brilliant) Windows Kernel developer
> struggle for a day or more with code that simply was not doing what he had
> expected. It was something like:
>
> if ( some_variable == TRUE )…
>
> It would never perform the target of the “if” statement even though
> some_variable was non-zero. As it turns out, the value of some-variable
> was 3, instead of TRUE (1). I’ve even seen some (very) bad coding style
> guidelines that actually say to do an explicit comparison to “true” or
> “false” as being somehow more readable than just using the expression
> and/or the NOT (!) operator!
>
> I only wish Microsoft had used a bit variable instead of a LONG in its
> broken BOOLEAN implementation (or is it DWORD, which is kinda like a LONG
> but unsigned…or is it signed? oh well). It would have surely made these
> things much less of a problem.
>
> Greg
>
>
> — xxxxx@storagecraft.com wrote:
>
> From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
> Subject: Re:[ntdev] Kernel Debugging over Network
> Date: Wed, 3 Dec 2014 18:40:45 +0300
>
> >> if (KD_DEBUGGER_NOT_PRESENT == FALSE)
> >
> > Never, ever, compare booleans with TRUE and FALSE.
> >
> > “Introduction to programming” for schoolchildren.
> >
[/quote]

> >
> > You’re going to have to break that one down for me Barney-style, Mr.
> Shatskih. Cuz while I think Mr. Geek’s advice is terrible, If I wanted to
> know if the debugger were present that’s how I could code it.
>
> Yes. Just do it this way:
>
> if (!KD_DEBUGGER_NOT_PRESENT)
> …
>
> :slight_smile:
>
> –
> Maxim S. Shatskih
>
> Microsoft MVP on File System And Storage
>
> xxxxx@storagecraft.com
>
> http://www.storagecraft.com
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

—
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

17

Ah… I see what you’re referring to.

With respect, KD_DEBUGGER_NOT_PRESENT global is only defined to have two values: 0 and 1.

Setting a BOOLEAN to something other than TRUE or FALSE (whatever patterns they represent… it should be opaque and not matter) kinda makes it not a BOOLEAN.

The underlying data type itself should be irrelevant. There are many ways to write broken code. Assigning “3” to value of type BOOLEAN is one of them. Even if the compiler lets you do it.

But thank you to you and Mr. Dyess for clarifying the intent.

Peter
OSR
@OSRDrivers

18

Thank you Mr. Cattley. I get Mr. Shatshih’s point now.

Peter
OSR
@OSRDrivers

(Don’t you love how the list server puts some replies in separate topics… it’s just a great feature of Lyris.)

19

Gregory G Dyess wrote:

I only wish Microsoft had used a bit variable instead of a LONG in its broken BOOLEAN implementation (or is it DWORD, which is kinda like a LONG but unsigned…or is it signed? oh well). It would have surely made these things much less of a problem.

Even worse, BOOLEAN is an unsigned char, but BOOL is an unsigned long.
Now there’s a good way to screw up a structure.

Sadly, there is no bit-sized type in C.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

20

> Never, ever, compare booleans with TRUE and FALSE.

Just do it this way: if (!KD_DEBUGGER_NOT_PRESENT) …

WTFIGO under that BIG FAT LAZY SUN ?

With all due respect, these are just plain stupid statements.

Comparing a boolean with 0 is always a good practice
because there is only one value that matches false and that
value is 0. Replacing (KD_DEBUGGER_NOT_PRESENT == FALSE)
with (!KD_DEBUGGER_NOT_PRESENT) is just stupid. What is the
point here ? Sorry but I can’t get the difference and if you
can, please, let me know.

The level of stupidity has reached the BIG FAT level here!
We have BIG WHALES!