I’m trying to use VS2013 community to debug my kernel mode miniport driver.
I have set up serial communication and have verified that both machines can talk to each other through serial port.
The host machine (all from VS2013) says that target is “Status: Configured for driver testing” (This is in Driver / Test / Configure computers dialog).
When I run debugger (Debug / Start debugging), my driver is recompiled and redeployed to target. Debugger immediate window shows progres just fine until the final deployment step “Driver Post Install Actions (x64) (possible reboot): Pass”.
At the bottom of Debugger immediate window, there is a separate edit box that says “Debuggee is running”. The edit box is unfocusable though, so I can’t type debugger commands in that.
At that point I’m expecting The debugger to be connected to target kernel and waiting for my commands or breakpoints.
However, the breakpoints I set never trigger though I know my code reaches them.
Note that I have run the debug setup commands:
bcdedit /set {current} debug yes
bcdedit /set {current} debugtype serial
bcdedit /set {current} debugport 1
bcdedit /set {current} baudrate 115200
Have you tried hitting the break all command from the debug menu of VS2013? It so happened to me once, that the debugger does not break automatically, we have to manually break it I guess.
also make sure the target machine is reachable via WinDBG.
try bcdedit /dbgsettings in the target machine and try connecting from WinDBG with the settings shown by the command.
I am assuming all the provisioning of the remote machine also went well.(Run C:\Program Files (x86)\Windows Kits\8.1\Remote\x64\WDK Test Target Setup x64-x64_en-us.msi on remote)
I tried WinDob a few times just now.
On the first try, it connected immediately, but complained a lot because I haven’t set symbol path. The connection also resulted in BSOD on the target (which WinDbg did not detect).
Subsequent tries were less successful: “Opened \.\com1 … Waiting to reconnect…” is all I got until I pressed ctrl + break. Only then did it proceed with symbol file loading.
The behaviour is unpredictable at best. Oh, just noticed that target was hung right now ??? Probably result of one of break operations
Running WDK Test Target setup on either machine doesn’t seem to do anything, at least not visually. Setup completes without any messages.
Trying out your final suggestion to break from IDE did the trick: the debugger really started working. However, it was super-slow (1 minute before all symbols were loaded) and even then it stopped at a completely different point in program - which was a little ways past the breakpoint I had set.
Also, target was again hung when I disconnected from debugger. I chose “Terminate all”.
So far thanks for the info, I’m finally getting somewhere
Well, after playing around some more, I got this far:
If I do the “Break all” command and then resume execution, debugger will stop on exceptions. This is a huge help from before when I could only guess origin of BSOD.
However, I still can’t get the debugger to break on my custom breakpoint. I set it in the IDE and it is listed in the Breakpoints list. However, it doesn’t break. Also if I do it using Debugger Immediate window (bp PRJ!func_name). It says “expression ‘PRJ!func_name’ could not be resolved, adding deferred bp”.
adding deferred breakpoint will happen if the module is not loaded
when you are setting the breakpoint and it may never break even if
the module is loaded and unloaded in between especially true when you
are setting breakpoints in csrss /winlogon etc during boot phase
a workaround in such cases is to catch the module load first and then
the breakpoint will be hit
On 4/2/15, xxxxx@gmail.com wrote: > Well, after playing around some more, I got this far: > If I do the “Break all” command and then resume execution, debugger will > stop on exceptions. This is a huge help from before when I could only guess > origin of BSOD. > > However, I still can’t get the debugger to break on my custom breakpoint. I > set it in the IDE and it is listed in the Breakpoints list. However, it > doesn’t break. Also if I do it using Debugger Immediate window (bp > PRJ!func_name). It says “expression ‘PRJ!func_name’ could not be resolved, > adding deferred bp”. > > Again, any help would be much appreciated. > > — > 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 >
Yes, I found that command, but the trouble is, when I call “Break All” from debug menu, the module is definitely already loaded. It’s a driver, it’s loaded immediately when deployment is complete, that is before the remote debugging session even starts.
I suppose if I restarted the driver, I’d get the notification, but otherwise it’s already strange that registering a breakpoint doesn’t work, since symbols should all be there already. AFAIK. Or maybe debugger needs to do something more before it is capable of registering breakpoints.
