none
how to load the driver on the target machine to invoke the debug in visual studio 2017 on host machine? RRS feed

  • Question

  • I am new to WDK and driver development and need to create a GPS driver, so I try to learn how to create a driver and test it.

    I found an example, gnss, in Microsoft Windows-driver-samples. It is in UMDF V2. In order to debug the driver with Visual Studio 2017, I followed video post on YouTube: "How to Set Up Kernel Debugging in Windows" posted by Programming LoL, in which the second half is for debugging the driver with Visual Studio. My target machine is set in Test mode, and Visual Studio 2017 on host machine is attached to debug successfully. However I don't know how to start the gnss driver so that the break point could be hit. In the video, OsrLoader is used to register and start the server through the .sys file, but no .sys file is seen in the UMDF driver.

    Any suggestion what to do to hit the breakpoint?

    Thanks a lot!

    Monday, July 22, 2019 1:36 AM

Answers

  • Are you setting breakpoints in gnssUmdf.dll, which is loaded into a user mode process WUDFHost.exe?
    0:005> lm
    start             end                 module name
    00007ff7`b4720000 00007ff7`b4765000   WUDFHost   (private pdb symbols)  c:\mssymbols\WUDFHost.pdb\713F8B754BD548679055259464984FA61\WUDFHost.pdb
    00007ffd`ecbf0000 00007ffd`ecd7a000   dbghelp    (pdb symbols)          c:\mssymbols\dbghelp.pdb\766CFDD649AB4C82A5ECD682D5FBB83F1\dbghelp.pdb
    00007ffd`f2720000 00007ffd`f27c8000   WUDFx02000   (private pdb symbols)  c:\mssymbols\Wudfx02000.pdb\9655395D8C30410598AE1CB4D299630D1\Wudfx02000.pdb
    00007ffd`fa500000 00007ffd`fa533000   WUDFPlatform   (private pdb symbols)  c:\mssymbols\WUDFPlatform.pdb\44C50F5BC57840BA8A11347156488BCA1\WUDFPlatform.pdb
    00007ffd`fe140000 00007ffd`fe146000   WppRecorderUM   (pdb symbols)          c:\mssymbols\WppRecorderUM.pdb\CC05E8E46DF9480DA46054989DFF9F351\WppRecorderUM.pdb
    00007ffd`fe190000 00007ffd`fe19d000   gnssUmdf   (private pdb symbols)  C:\Developer\gnss\gnssUmdf\bin\x64\Debug\gnssUmdf.pdb
    ...
    Debugging a user-mode process from kernel debugger is (in my opinion) quite 'awkward'.

    Didn't do it for a while, but IIRC this was helpful for setting breakpoints:
    https://www.osronline.com/article.cfm%5Earticle=576.htm
    if you have problems with remote-debugging from VS (user-mode) Debug->Attach to Process ...

    then I would rather attach windbg (user-mode), the one which is normally installed on debugging target during WDK provisioning (though not quite sure about the status of provisioning on your target at the moment), and set symbol-path and source-path accordingly - e.g. therefore my driver projects live on a network share accessible by the target. 

    No warranty

    With kind regards

    Tuesday, July 23, 2019 5:35 PM

All replies

  • Did you check the Readme.md? There are several test methods to test gnss driver.

    https://github.com/microsoft/Windows-driver-samples/tree/master/gnss

    An UMDF driver is a dll which means you need an application to interactive with.



    Ivellios Colin

    Monday, July 22, 2019 1:42 AM
  • Having not the slightest idea, what this driver is about ...
    I did not look it up in detail, but there is a tutorial how to debug a umdf driver including installation with devcon:
    https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/videos--debugging-umdf-drivers
    Looks for me, like this one does not do much out of the box, but probably I am missing something:

    No warranty

    With kind regards

    Monday, July 22, 2019 10:32 AM
  • In case automatic driver deployment is working for you, you may even try:
    Using Visual Studio with F5 to attach automatically (user-mode debugging)
    https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/enabling-a-debugger

    ('Hardware ID' depending on your inf file):

    With kind regards

    Monday, July 22, 2019 11:57 AM
  • I tried F5, but always failed with the following deploy error. It seems Remote Debugger is used:

    Deploying driver files for project "C:\BJ\gnss\gnssUmdf\gnssUmdf.vcxproj".  Deployment may take a few minutes...
    [11:06:40:998]: Gathering kernel debugger settings
    [11:06:41:001]: Removing any existing files from test execution folder.
    [11:06:41:058]: Copying required files for "Gathering kernel debugger settings".
    [11:06:43:654]: [Gathering kernel debugger settings] Command Line:
    $KitRoot$\Testing\Runtimes\TAEF\te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"@Name='DriverTestTasks::_LogDebuggerSettings'" /rebootStateFile:%SystemDrive%\DriverTest\Run\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Run\Gathering_kernel_debugger_settings_00029.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated
    [11:06:50:036]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0
    [11:06:50:039]: Task "Gathering kernel debugger settings" completed successfully
    [11:06:50:978]: Remove Existing Remote Package
    [11:06:51:110]: Task "Remove Existing Remote Package" completed successfully
    [11:06:51:115]: Copy Driver Package
    [11:06:51:383]: Task "Copy Driver Package" completed successfully
    [11:06:51:394]: Driver Removal
    [11:06:51:395]: Removing any existing files from test execution folder.
    [11:06:51:417]: Copying required files for "Driver Removal".
    [11:06:54:052]: [Driver Removal] Command Line:
    $KitRoot$\Testing\Runtimes\TAEF\te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"@Name='DriverTestTasks::_DriverRemoval'" /p:"InfFile=gnssUmdf.inf" /p:"Debug=1" /p:"UserMode=1" /p:"ImportDriver=1" /p:"RemoveDriver=1" /p:"CertificateFile=gnssUmdf.cer" /p:"PackageGuid=x64" /p:"HardwareId=Root\gnssUmdf" /rebootStateFile:%SystemDrive%\DriverTest\Run\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Run\Driver_Removal_00025.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated
    [11:06:55:296]: Result Summary: Total=1, Passed=0, Failed=1, Blocked=0, Warned=0, Skipped=0
    [11:06:55:299]: ERROR: Task "Driver Removal" failed to complete successfully. Look at the logs in the driver test group explorer for more details on the failure.
    [11:06:55:640]: Driver Preparation
    [11:06:55:640]: Removing any existing files from test execution folder.
    [11:06:55:677]: Copying required files for "Driver Preparation".
    [11:06:58:229]: [Driver Preparation] Command Line:
    $KitRoot$\Testing\Runtimes\TAEF\te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"@Name='DriverTestTasks::_DriverPreparation'" /p:"InfFile=gnssUmdf.inf" /p:"Debug=1" /p:"UserMode=1" /p:"ImportDriver=1" /p:"RemoveDriver=1" /p:"CertificateFile=gnssUmdf.cer" /p:"PackageGuid=x64" /p:"HardwareId=Root\gnssUmdf" /rebootStateFile:%SystemDrive%\DriverTest\Run\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Run\Driver_Preparation_00025.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated
    [11:07:01:528]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0
    [11:07:01:530]: Task "Driver Preparation" completed successfully
    [11:07:01:881]: Driver Install
    [11:07:01:881]: Removing any existing files from test execution folder.
    [11:07:01:915]: Copying required files for "Driver Install".
    [11:07:04:271]: [Driver Install] Command Line:
    $KitRoot$\Testing\Runtimes\TAEF\te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"@Name='DriverTestTasks::_RunProcess'" /p:"BinaryPath=%SystemDrive%\DriverTest\devcon.exe" /p:"Arguments=-f install %SystemDrive%\DriverTest\Drivers\gnssUmdf.inf Root\gnssUmdf" /p:"WorkingFolder=%SystemDrive%\DriverTest\Drivers" /rebootStateFile:%SystemDrive%\DriverTest\Run\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Run\Driver_Install_00023.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated
    [11:07:05:488]: Result Summary: Total=1, Passed=0, Failed=1, Blocked=0, Warned=0, Skipped=0
    [11:07:05:490]: ERROR: Task "Driver Install" failed to complete successfully. Look at the logs in the driver test group explorer for more details on the failure.
    [11:07:05:846]: Driver Post Install Actions
    [11:07:05:846]: Removing any existing files from test execution folder.
    [11:07:05:876]: Copying required files for "Driver Post Install Actions".
    [11:07:08:458]: [Driver Post Install Actions] Command Line:
    $KitRoot$\Testing\Runtimes\TAEF\te.exe "%SystemDrive%\DriverTest\Run\DriverTestTasks.dll" /select:"@Name='DriverTestTasks::_DriverPostInstall'" /rebootStateFile:%SystemDrive%\DriverTest\Run\DriverTestReboot.xml /enableWttLogging /wttDeviceString:$LogFile:file="%SystemDrive%\DriverTest\Run\Driver_Post_Install_Actions_00021.wtl",writemode=append,encoding=unicode,nofscache=true,EnableLvl="WexStartTest|WexEndTest|WexXml|WexProperty|WexCreateContext|WexCloseContext|*" /runas:Elevated
    [11:07:09:684]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0
    [11:07:09:686]: Task "Driver Post Install Actions" completed successfully
    Driver Deployment Task Failed: Driver Removal
    Driver Deployment Task Failed: Driver Install
    

    If change to Kernel Debugger, got the following error:

    "Windows Debugging Extension for Visual Studio

    Failure to create process instance prevents debugging"


    Tuesday, July 23, 2019 3:35 PM
  • Tried to require the location from location service. The hardcoded location in gnssUmdf driver does be returned, but the breakpoint in Visual Studio is not hit. I am wondering if I missed any configuration?

    I followed the steps on the target machine to setup test mode:

    • Command: bcdedit /debug on
    • Command: bcdedit/dbgsettings net hostip:<ip address> port:53000
    • Command: bcdedit /set testsigning on
    • Restart target machine

    On the host machine, in Visual Studio 2017, configure the driver and attach to the Windows Kernel Mode Debugger to the target machine. The debug starts without any issue.

    Then use a simple html application to query the location through navigator.geolocation.getCurrentPosition function. The hardcoded location in the gnssUmdf driver is returned while the breakpoint set in Visual Studio 2017 is not hit.

    Tuesday, July 23, 2019 3:47 PM
  • Are you setting breakpoints in gnssUmdf.dll, which is loaded into a user mode process WUDFHost.exe?
    0:005> lm
    start             end                 module name
    00007ff7`b4720000 00007ff7`b4765000   WUDFHost   (private pdb symbols)  c:\mssymbols\WUDFHost.pdb\713F8B754BD548679055259464984FA61\WUDFHost.pdb
    00007ffd`ecbf0000 00007ffd`ecd7a000   dbghelp    (pdb symbols)          c:\mssymbols\dbghelp.pdb\766CFDD649AB4C82A5ECD682D5FBB83F1\dbghelp.pdb
    00007ffd`f2720000 00007ffd`f27c8000   WUDFx02000   (private pdb symbols)  c:\mssymbols\Wudfx02000.pdb\9655395D8C30410598AE1CB4D299630D1\Wudfx02000.pdb
    00007ffd`fa500000 00007ffd`fa533000   WUDFPlatform   (private pdb symbols)  c:\mssymbols\WUDFPlatform.pdb\44C50F5BC57840BA8A11347156488BCA1\WUDFPlatform.pdb
    00007ffd`fe140000 00007ffd`fe146000   WppRecorderUM   (pdb symbols)          c:\mssymbols\WppRecorderUM.pdb\CC05E8E46DF9480DA46054989DFF9F351\WppRecorderUM.pdb
    00007ffd`fe190000 00007ffd`fe19d000   gnssUmdf   (private pdb symbols)  C:\Developer\gnss\gnssUmdf\bin\x64\Debug\gnssUmdf.pdb
    ...
    Debugging a user-mode process from kernel debugger is (in my opinion) quite 'awkward'.

    Didn't do it for a while, but IIRC this was helpful for setting breakpoints:
    https://www.osronline.com/article.cfm%5Earticle=576.htm
    if you have problems with remote-debugging from VS (user-mode) Debug->Attach to Process ...

    then I would rather attach windbg (user-mode), the one which is normally installed on debugging target during WDK provisioning (though not quite sure about the status of provisioning on your target at the moment), and set symbol-path and source-path accordingly - e.g. therefore my driver projects live on a network share accessible by the target. 

    No warranty

    With kind regards

    Tuesday, July 23, 2019 5:35 PM
  • User-mode WinDbg works fine on the target machine. I will debug with it. Thanks a lot!
    Thursday, July 25, 2019 1:13 PM