Once I started my driver project I was able to debug the driver in source and with breakpoints etc, it was loading symbols fine. At some point the symbols stopped loading and I have no idea what happened. What I tried so far :
Altering symbol cache path to include location of my pdb
Pushing my pdb to the VM and adding itâs path to the sympath
Forcing a reload of all symbols after the changes
Enabling and disabling âRequire source files to exactly match original versionâ
Changing symbol cache path
Adding _NT_SYMBOL_PATH and _NT_ALT_SYMBOL_PATH to point to a directory containing pdb
Using Ld command (altough I wasnt able to make load absolutely anything, it just complains that module isnât found).
The only temporary fix I managed to get working was setting SYMOPT_LOAD_ANYTHING and using âreload /f /i mydriver.sysâ, and it cached the exact binary version of the symbol file under a hash, and that is not great as it changes every recompile obviously. Thatâs a pain in the ass, and I want to get automatic loading back, what am I missing, this is gonna give me a stomach ulcer, Iâm loosing days of productive work due to the damn debugger failing all the time.
Donât know what could âjust suddenly breakâ like that.
Letâs start with the basics: every time you build your driver, a new PDB and executable are generated⌠and those get a GUID to uniquely identify them. So they have to match exactly.
If youâre developing and debugging in the same machine, which is ideal, and youâre doing debug builds, the executable will have a debug section that contains a path to the PDB⌠so finding the PDB should be automatic.
My best advice: set !sym noisy and watch the search for your PDB. This should solve the mystery.
And never try to debug a driver from within VS⌠always use WinDbg.
I test the drive in VMWare workstation, cause I crash the kernel constantly, and I need to rollback to a snapshot many many times.
I debug from my local machine to a VM on the same machine. Yes I do build in debug mode. I do get a .pdb file that I can load.
I had it working with VS, it was working, and now Itâs not. I was able to do source level debugging with it, and now I canât. Itâs as if a moon phase has shifted. Has anyone ever had any positive experience with using Visual Studio for driver debugging or is it just so broken everyone gave up ?
I can force reload the module and then do it, but itâs slow as molases, and VS freezes completely every 2nd or 3rd time i try.
And I have no idea how to do source level debugging in WinDBG, itâs so arcane, looks like it was coded in 1992, and breaks my concentration to have to keep switching between VS and WinDBG. I want to fix it to the state it was before if at all possible.
And even in PURE WinDBG, itâs not loading the symbols automatically, I have to force it.
I teach people how to write and debug drivers. The first few times they have to do so, they struggle with getting WinDbg set up. After that⌠smooth sailing.
Take the advice of somebody whoâs been doing this a long time: Do not try to debug your driver from within VS. Use WinDbg. Itâs what itâs designed for. If switching back and force âbreaks [your] concentrationâ I recommend you work a little harder on developing your focus.
I have no idea how to do source level debugging in WinDBG, itâs so arcane,
Really? You ever debug a driver in Linux? Source level debugging is simple. It works the almost identically to the way it works in VS. You click a line. You set a breakpoint. You single-step with F10 or F11. How hard is that?
Sorry for ranting, I was just super frustrated. I got the preview WinDBG of the windows store, and thank god that is working pretty well so far.
Thank you for the reply, much appretiated. For the record I was using the old WinDBG included in Win DDK, and that one was pretty hard to figure out.
I never debugged anything in linux besides some basic apps. This is my first driver ever.
I am too used to nice things i guess :neutral:
Sorry for sounding like a whiny baby