-3

I have recently started windows driver development. I am wondering how does it actually debug my driver. The setup I have is --> Win7 as host, XP as guest on VMware, and I am debugging through serial port.

The research I have done:

I found only this link saying very few things that I am talking about.

I already know how debugger works on single OS, in that case debugger is also on the same OS, so it knows which process is running. That is understandable. But here, debugger is on entirely different OS, an entirely different environment. I just say file->open source files and I AM able to put breakpoints!! Moreover when I load driver, it actually breaks there. I mean why../How? How does XP's kernel comes to know(drivers are extension to kernel, atleast WDM, don't know about WDK) that there is source code of this driver? and that also outside its control(environment)? I mean I can have 10 files open with breakpoint in them, but it works beautifully, I am not able to fail/fool it.

So what I am thinking is like, whenever we add source to windbg on Win7, it creates the binary from that source, and whenever XP is going to load any binary, it checks if this is the binary that windbg is waiting for. what is confusing in above link is, Vikrant is saying that debugger asks kernel(XP) that it is willing to debug a process --> Bus HELLO... process is running on XP, and windbg on Win7 and does not know name or id of process. It has source code, but consider a case where there is a driver which is build out of 300 files, and just one, probably simplest file is open in windbg, how it matched that this source code is of the driver being run?

  • you may be elite, but enlighten me with your thought if you are down voting. This silence kills me..:D –  Oct 10 '13 at 19:55
  • You can try reading this book : https://blogs.msdn.microsoft.com/microsoft_press/2012/05/31/new-book-inside-windows-debugging/ – Yijinsei Jun 01 '16 at 14:34

2 Answers2

1

@Kjelll answer is correct. Here is the full scenario, including explanation to your comment:

  1. PDB files have line information. This is a mapping from each (file,line) location to address (RVA - relative virtual address).
  2. When you set a break point on a source file, WinDBG checks whether this source file correspond to a current address. If it is - it sets the breakpoint. Otherwise, it becomes a "future breakpoint" (not sure whether Microsoft uses this terminology).
  3. When a new binary is a loaded, the agent on the client communicates with the host, informs it about the binary. At this point - WinDBG will try to allocate a PDB file.
  4. WinDBG will start at the PDB location embedded within the file. You can see this value by using this command line: windbg -dump -pdbpath xxx.sys. This should explain how WinDBG will find a symbol file even if not on the .sympathy path (that I believe answers your comment to Kjell).
  5. WinDBG will then search at the .sympathy.
  6. Once symbol is find, it will look at all future breakpoint, and if applicable will set an actual breakpoint.
Uri London
  • 10,631
  • 5
  • 51
  • 81
0

I think your link explain your question pretty well, but you have probably not realized what the mechanism of the pdb do for the debugger. The windbg on your host OS uses the pdb file to translate line nubers in the source files to addresses in your guest OS (xp) . Then the the debugger agent uses this address to set break points (Int 3) in the guest OS.This is much in the same way as a local debugger do to a local process.

Kjell Gunnar
  • 3,017
  • 18
  • 24
  • But i never set the pdb file path. Didn't you read the steps i took to debug the driver? pdb file for my drivers could be at ANY location, is WinDbg going to search my entire HDD for a particular pdb file.. :D..? –  Oct 10 '13 at 02:20
  • I have never ever had the opportunity to anything at all with source code in windbg without setting the Symbol file path to the correct .pdb - sorry – Kjell Gunnar Oct 10 '13 at 07:25