none
Visual Studio 2013 kernel debug operation inconsistent RRS feed

  • Question

  • Hello.

    I am developing a KMDF driver on a Windows 7 machine running Visual Studio 2013. My target machine is running Windows 8.1. I am using a network connection that connects the host and target machines.

    I am having trouble consistently hitting breakpoints I have set using the Visual Studio environment. I am provisioning the driver using the environment. 

    Once the provisioning is completed with a successful Driver installation summary , I hit the break-all button on Visual Studio to be sure I can get control of the remote driver. I often set breakpoints in various routines at this time. I then continue the driver. 

    I am using a simple test program on the target machine to exercise my driver. Sometimes the breakpoints in the driver are hit. Oftentimes the breakpoints aren't hit and I have to start over. I am debugging DMA code.

    I have a colleague who is running into the same problem and we are looking for the procedure that will make hitting breakpoints more reliable. Is there a procedure for setting breakpoints that we are missing?

    Thanks,

    Brian

    Tuesday, December 3, 2013 7:55 PM

Answers

  • Hi Brian,

    Unfortunately, there are some cases where breakpoints set in VS through the UI are not 100% reliable, which could explain the issue you are encountering. I have two workarounds for you:

    • You can set breakpoints using the WinDbg command window that opens in Visual Studio when you start debugging your remote driver (I don't remember its exact name, but it's the debugger window that shows debugging information for the target machine). You should be able to use all standard WinDbg commands in there ("bp", "bl", "be" and "bd" are good starting points for breakpoints), and those commands should be more reliable that the Visual Studio UI breakpoints.
    • If the above still doesn't work, you can also try debugging your driver with WinDbg without going through the VS UI.

    I hope this helps!


    Max -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, December 3, 2013 9:07 PM

All replies

  • Hi Brian,

    Unfortunately, there are some cases where breakpoints set in VS through the UI are not 100% reliable, which could explain the issue you are encountering. I have two workarounds for you:

    • You can set breakpoints using the WinDbg command window that opens in Visual Studio when you start debugging your remote driver (I don't remember its exact name, but it's the debugger window that shows debugging information for the target machine). You should be able to use all standard WinDbg commands in there ("bp", "bl", "be" and "bd" are good starting points for breakpoints), and those commands should be more reliable that the Visual Studio UI breakpoints.
    • If the above still doesn't work, you can also try debugging your driver with WinDbg without going through the VS UI.

    I hope this helps!


    Max -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, December 3, 2013 9:07 PM
  • In general one of the problems that earlier debugging environments had in the kernel was that breakpoints were not always set till the debugger had been broken into after the driver was loaded.  You will see a lot of us who have been doing driver development for a long time, having a breakpoint in DriverEntry, or the ultimate a registry variable such as "BreakOnEntry" that then triggers a KdBreakPoint() if the value is set.

    I haven't tried VS2013 for debugging yet, but in general for safety using a hardcoded breakpoint is a good way to start.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Tuesday, December 3, 2013 9:16 PM
  • Thanks for the recommendations. I was in the situation where I could get control of the driver after it had loaded but any breakpoints I set while I had control were ineffective. I found that if you get out of visual studio, delete the .sdf and .suo project files, and then restart visual studio and make sure I was using x64 and Win8.1 debug configuration, I could get breakpoints again. This bizarre sequence worked at least once for me.

    Cheers,

    Brian

     
    Tuesday, December 3, 2013 10:24 PM
  • Trying to debug a kmdf driver with vs2013 on two W7/32 machines I have noticed that, after provisioning the driver through the IDE via the debugger,  it does not show that the driver module is loaded ( using cmd lm or lml) after you break into the debugger with a "Break All" command. Also when listing the breakpoints (using cmd bl) at that time it is indicated that they are associated with a an "unloaded" instance of my driver.

    This somewhat  explains why the breakpoints are not hit on first load of the driver during provisioning, but I'm confused as to why there is an unloaded instance of my driver in the first place. 

    I can get BPs to trigger only after I  disable the driver on the target machine via the HW-Config Manager, then break into the debugger, clear all breakpoints and set a new BP on DriverEntry before letting the debugger go again.  The BP triggers when I then re-enable the driver  in the config_manager as it starts loading it anew. However the BPs set in this way are only good for that run of the driver and you have to go through the whole sequence of removing and resetting of the BPs again if you want them to trigger again on the next start or shutdown.

    An other problem I have is that when I'm actually in the debugger and step through the code the debugger times out if I try to look a data, say for example devContext->.  The debug machine eventually crashes and the debuggee is locked up tighter than a frogs ass, only recourse is to pull the power cord on it.  This lockup happens if you only move the cursor inadvertently over a pointer to a large structure, or maybe it has to do where the data is located in memory or something.

    There was a brief period of maybe 30 minutes when debugging actually worked as it was supposed to, when the debugger came up during the initial driver start-up in the provisioning phase and on every subsequent disable/enable of the driver, but I have no clue what made it work. After I exited VS and restarted the solution again the honeymoon was over.

    Thursday, September 11, 2014 3:17 PM