none
Getting "Driver verifier settings file was not found" during deployment step. RRS feed

  • Question

  • I am developing a KMDF driver from an existing WDM driver. I am using Visual Studio 2012 and have used the sample KMDF framework as a starting point. I am using a Windows Server 2012 as my target machine and a Windows 7 system as my host machine.

    The target server is attached straight via a network cable to my host machine on a private network. I have set the adapters to use static IP addresses.

    I have used the process "Driver->Test->ConfigureComputers" in Visual Studio on my host to deploy the test/development environment. This has not gone as smoothly as I had hoped it would. I suspect this is where my problems emanate from.

    The driver build OK. My problem occurs during the deployment stage.  Here is the text from Visual Studio during the deployment:

    1>DriverTestSign:
    1>  Sign Inputs: C:\projects\dts9080\x64\Win8Debug\dts9080.sys
    1>  Done Adding Additional Store
    1>  Successfully signed: C:\projects\dts9080\x64\Win8Debug\dts9080.sys
    1>  
    1>  Certificate used for signing: issued to = WDKTestCert moo59629,130180306076899547 and thumbprint = E87C22EB74AFB3BC441AF0BE21A0344147EE14C2
    1>  Exported Certificate: C:\projects\dts9080\x64\Win8Debug\dts9080.cer
    1>FinalizeBuildStatus:
    1>  Deleting file "x64\Win8Debug\dts9080.unsuccessfulbuild".
    1>  Touching "x64\Win8Debug\dts9080.lastbuildstate".
    1>
    1>Build succeeded.
    1>
    1>Time Elapsed 00:00:03.79
    2>------ Rebuild All started: Project: dts9080 Package, Configuration: Win8 Debug x64 ------
    2>Build started 9/11/2013 12:42:00 PM.
    2>_PrepareForClean:
    2>  Deleting file "x64\Win8Debug\dts9080 Package.lastbuildstate".
    2>CleanOutput:
    2>  Deleting file "x64\Win8Debug\dts9080 Package.unsuccessfulbuild".
    2>InitializeBuildStatus:
    2>  Creating "x64\Win8Debug\dts9080 Package.unsuccessfulbuild" because "AlwaysCreate" was specified.
    2>DriverPackageTarget:
    2>  Packaging up the following projects for the following configurations:
    2>  
    2>  ..\dts9080\dts9080.vcxproj Configuration='Win8 Debug' Platform='x64'
    2>  
    2>  
    2>  The following files will be packaged:
    2>  
    2>  File to package:      C:\projects\dts9080\x64\Win8Debug\dts9080.sys.
    2>  Location in Package:  \dts9080.sys.
    2>  Requested by project: C:\projects\dts9080\dts9080.vcxproj
    2>  
    2>  
    2>  File to package:      C:\projects\dts9080\x64\Win8Debug\dts9080.inf.
    2>  Location in Package:  \dts9080.inf.
    2>  Requested by project: C:\projects\dts9080\dts9080.vcxproj
    2>  
    2>  
    2>  File to package:      C:\Program Files (x86)\Windows Kits\8.0\redist\wdf\x64\WdfCoinstaller01011.dll.
    2>  Location in Package:  \WdfCoinstaller01011.dll.
    2>  Requested by project: C:\projects\dts9080\dts9080.vcxproj
    2>  
    2>  
    2>  Creating directory "C:\projects\dts9080\x64\Win8Debug\dts9080 Package".
    2>  Copying file from "C:\projects\dts9080\x64\Win8Debug\dts9080.sys" to "C:\projects\dts9080\x64\Win8Debug\dts9080 Package\\dts9080.sys".
    2>  Copying file from "C:\projects\dts9080\x64\Win8Debug\dts9080.inf" to "C:\projects\dts9080\x64\Win8Debug\dts9080 Package\\dts9080.inf".
    2>  Copying file from "C:\Program Files (x86)\Windows Kits\8.0\redist\wdf\x64\WdfCoinstaller01011.dll" to "C:\projects\dts9080\x64\Win8Debug\dts9080 Package\\WdfCoinstaller01011.dll".
    2>Inf2Cat:
    2>  ......................
    2>  Signability test complete.
    2>  
    2>  Errors:
    2>  None
    2>  
    2>  Warnings:
    2>  None
    2>  
    2>  Catalog generation complete.
    2>  C:\projects\dts9080\x64\Win8Debug\dts9080 Package\dts9080.cat
    2>DriverTestSign:
    2>  Sign Inputs: C:\projects\dts9080\x64\Win8Debug\dts9080 Package\dts9080.cat
    2>  Done Adding Additional Store
    2>  Successfully signed: C:\projects\dts9080\x64\Win8Debug\dts9080 Package\dts9080.cat
    2>  
    2>  Certificate used for signing: issued to = WDKTestCert moo59629,130180306076899547 and thumbprint = E87C22EB74AFB3BC441AF0BE21A0344147EE14C2
    2>  Exported Certificate: C:\projects\dts9080\x64\Win8Debug\dts9080Package.cer
    2>Deploy:
    2>  Deploying driver files for project "C:\projects\dts9080 Package\dts9080 Package.vcxproj".  Deployment may take a few minutes...
    2>  [12:42:02:289]: Removing any existing files from test execution folder
    2>  [12:42:06:372]: Gathering debugger settings from machine "driverdev"
    2>  [12:42:08:539]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0
    2>  [12:42:09:112]: Removing any existing files from test execution folder
    2>  [12:42:09:420]: Gathering driver verifier settings from machine "driverdev"
    2>  [12:42:11:553]: Result Summary: Total=1, Passed=1, Failed=0, Blocked=0, Warned=0, Skipped=0
    2>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Platforms\x64\ImportAfter\DriverDeployment8.0.targets(69,9): error : Driver verifier settings file was not found
    2>
    2>Build FAILED.
    2>
    2>Time Elapsed 00:00:11.53
    ========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========

    I don't know if I have deleted a file by accident that is causing this error. Does anyone know how I can get past this point?

    Thanks,

    Brian

     
    Wednesday, September 11, 2013 4:45 PM

Answers

  • The server OS is likely the issue: there is a bug that we found recently that only affects Server OS and that we couldn't fix in time for the 8.1 release.

    Workaround is the following: on the target machine, add "Authenticated Users" with modify rights on the C:\DriverTest directory tree. Then try provisioning again.

    The issue occurs because the default permissions on a server OS are different than on a non-server one. When the driver test service creates the DriverTest directory, it uses the default permissions, which on Server OS prevents the tasks to resume after reboot.


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

    Friday, September 13, 2013 6:25 PM

All replies

  • Was the remote computer configuration successful, or did one of the steps fail? In WDK 8, it is possible for configuration to partially fail, which can lead to weird issues like this.

    The file that is missing should be on the target machine at C:\DriverTest\Run\WexLogFileOutput\VerifierSettings.txt . This file is created at driver deployment time by running a remote task on the target machine, so in your case, it looks like that remote task was not executed properly or the file was not accessible.

    It is not clear to me why the file is missing, given that the task apparently succeeded... I suggest disabling driver verifier (which you can do from the driver package menu) and try deployment again to see if it succeeds without it. You can always enable driver verifier again later.

    I would also recommend using WDK 8.1, which was just released following Windows 8.1 RTM, as it fixes a lot of issues related to what you are encountering.


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

    Wednesday, September 11, 2013 6:22 PM
  • That file is missing. I will update to WDK 8.1 and try again.

    Thanks.

     
    Wednesday, September 11, 2013 7:29 PM
  • Note that if you do update to WDK 8.1, you will need Visual Studio 2013. The release candidate version of VS 2013 should be available online.

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

    Wednesday, September 11, 2013 7:31 PM
  • Max,

    Thanks for the directions. I tried updating to Visual Studio 2012 RC. I tried the Professional version first. I downloaded the .iso file and tried installing it. Early in the process I get two errors:

    Visual Studio 2013 Prerequisites   Incorrect function.

    Microsoft .Net Framework 4.5.1 RC operation aborted.

    I then manually installed the .NET Framework.

    Tried again and got the same Prerequisites error. Unclear as to what prerequsites are missing or fouled up. I saw another blog recommending trying Visual Studio 2013 RC Ultimate. I downloaded this and got it installed. 

    I tried to launch my KMDF driver solution in VS Ultimate. The loading of the solution was unsuccessful. Ultimately I got a dialog indicating "The operation could not be completed.  Unspecified error".

    I am back trying to get the Visual Studio 2012 provisioning working. 

    I took a Wireshark trace to see what if any communication is occurring between my host and target machines. There is an infinite loop with the host trying to read a DriverTestSvc file. The target returns a GetInfo response : Error: STATUS_FILE_CLOSED.   

    I think I am 95% of the way to getting this working.  The last 5% is tough.

    Cheers.

     

    Thursday, September 12, 2013 6:55 PM
  • You need to install WDK 8.1 after installing VS 2013 for the driver project to be loadable in VS 2013 (the installation order is important). VS should then prompt you to upgrade your project to the latest WDK version.

    That being said, DriverTestSvc is the remote service that is running on the target machine. Make sure it is running on the target (you might want to restart it to be sure): with WDK 8, the name of the service in services.msc is "DTSvc". I know that in WDK 8, the service can sometimes get stuck at startup time, so that could be the issue you're encountering.

    Did you try turning off driver verifier to see if that fixed the issue (or brought up another problem)?


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

    Thursday, September 12, 2013 7:01 PM
  • Max,

    I will look at loading WDK 8.1.

    I checked and the service DTsvc is running. I will re-start it to see the effect. I did turn off the driver verifier.

    Just re-started the DTSVC service. Rebuilt my project. This time, I get "Gathering debugger settings failed" message. I figure this is due to the provisioning process not completing properly.

    Can I manually complete the provisioning process?  Driver Verification is mucked up as well as the debugger settings.

    Thanks for your help.

    Brian

    Thursday, September 12, 2013 7:47 PM
  • You can do the provisioning process again (Driver / Test / Configure Computers...), and steps that have already succeeded should pass very quickly. You should try doing that to make sure that everything was provisioned properly initially.

    You can also see the original provisioning logs by going to the driver test group explorer (Driver / Test / Test Group Explorer) and looking under "Driver Installation". The logs in there might be helpful to identify if something went wrong.


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

    Thursday, September 12, 2013 7:50 PM
  • Max,

    I am downloading WDK 8.1 right now. Would you recommend I try re-provisioning again on VS 2012 before upgrading to VS 2013?

    Thanks.

    Brian

    Thursday, September 12, 2013 7:59 PM
  • I would recommend you use WDK 8.1 and the driver test service that comes with it. WDK 8.1 has better errors messages and handling, and has a better remote service has well, so it should help in your case.

    Make sure to unprovision the target machine with VS2012 before using VS2013 though. If unprovisioning doesn't work for some reason, you should at least manually uninstall the DTSvc service from the target machine before moving to VS2013.


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

    Thursday, September 12, 2013 8:03 PM
  • Max,

    I have installed WDK 8.1 successfully on my host machine. I had to uninstall WDK 8.0 before the Visual Studio 2013 RC would recognize my KMDF driver solution.

    I removed the DTsvc service from my target machine and used the  WDK Test Target Setup x64-x64_en-usi.msi file from the c:\Program Files (x86)\Windows Kits\8.1\Remote\x64 subdirectory on my host machine to install the latest test service on my target machine.

    When I try to Configure the Computers, I get this:

    Progress event: Current: 0, Max: -1, Message: "Connecting to computer "driverdev""
    Initialize: Computer: driverdev
    InstallComputer: Host Computer: J5YN1Q1
    InstallComputer: Host Architecture: x86
    InstallComputer: Host 64bit Operating System: True
    InstallComputer: Host Operating System Version: 6.1.7601.65536
    InstallComputer: Process Administrator Privilege: True
    Progress event: Current: 1, Max: 17, Message: "Connecting to driver test automation service"
    [12:48:33:198]: The driver test service installed on remove machine driverdev does not match the WDK version you are using. Please uninstall the driver test service from the remote machine, and then run the WDK Test Target Setup installer on the remote machine. The installer for each architecture is located at C:\Program Files (x86)\Windows Kits\8.1\Remote
    Progress event: Current: 1, Max: 17, Message: "The driver test service installed on remove machine driverdev does not match the WDK version you are using. Please uninstall the driver test service from the remote machine, and then run the WDK Test Target Setup installer on the remote machine. The installer for each architecture is located at C:\Program Files (x86)\Windows Kits\8.1\Remote"
    Progress event: Current: 1, Max: 17, Message: "Computer configuration log file://C:/Users/MOO59629/AppData/Roaming/Microsoft/DriverTest/Install/Driver%20Test%20Computer%20Configuration%2020130913124832889.log"

    The file I used was from the WDK 8.1 preview.

    Any ideas?

    Thanks,

    Brian

     
    Friday, September 13, 2013 4:50 PM
  • When you removed the DTSvc service from the target machine, did you also delete the executable (I think it's located in C:\Windows\System32)? If not, then when you installed the new MSI for the 8.1 service, the exe for the service was likely not overwritten, thus leading to that issue.

    Uninstall "WDK Test Target Setup" from the target (you can do that from the Control Panel / Uninstall Programs menu, this will also uninstall the service), make sure the DTSvc.exe file is not in you System32 folder (delete it if it is) and then reinstall "WDK Test Target Setup" (make sure that a new version of DTSvc.exe is then added in System32).


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

    Friday, September 13, 2013 4:56 PM
  • Max,

    I performed the operations above and I am getting further along. Now on my host, the Configuration Progress dialog indicates it has installed many things. After "Configure computer settings (x64) (possible reboot) is displayed, my target machine did reboot.

    Now "Attempting to connect..." is displaying multiple times. The target machine has re-booted. There is communication between the host and target (using wireshark to monitor). I am getting the infinite loop exchange where it looks like the host is making a GetInfo request and the target is giving a GetInfo response of Error: STATUS_FILE_CLOSED. There is an Ioctl request for a NAMED_PIPE Function:0x0006 from the host. The host makes a request file: "DriverTestSvc". There is a write response from the host. Then there is a Read Response, ERROR: STATUS_PENDING. The host then makes a close request and there is a close response from the target.

    I feel I am close here. I tried re-starting the WDK Driver Test Service and nothing changed. The host is still trying to connect.

    Next step?

    Thanks,

    Brian

    Friday, September 13, 2013 5:44 PM
  • Is your target OS a Windows Server OS?

    After the target reboot (while the host is attempting to connect), are you able to ping the target machine by name from the command line ("ping machine-name")?


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

    Friday, September 13, 2013 6:09 PM
  • Yes. The target computer is running Windows Server 2012 Standard edition.

    I am able to ping the target system from my host. I have an entry in my host file for the name "driverdev" with the IP address of the target in my host. This is working. Driverdev is the name of my target computer. 

    I am wondering if there is a server setting that is blocking this operation. The server has allowed me to install multiple files during the configuration process.  

    Thanks,

    Brian

    Friday, September 13, 2013 6:15 PM
  • The server OS is likely the issue: there is a bug that we found recently that only affects Server OS and that we couldn't fix in time for the 8.1 release.

    Workaround is the following: on the target machine, add "Authenticated Users" with modify rights on the C:\DriverTest directory tree. Then try provisioning again.

    The issue occurs because the default permissions on a server OS are different than on a non-server one. When the driver test service creates the DriverTest directory, it uses the default permissions, which on Server OS prevents the tasks to resume after reboot.


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

    Friday, September 13, 2013 6:25 PM
  • Max,

    I added Full Control to the Users for c:\DriverTest subdirectory. I don't know if that is "Authenticated Users" as you suggest.

    I tried to re-provision that target machine. I get a failure at the end indicating it can't make a restore point. i understand on a server, you can't. The host side still shows this a failure.

    I tried building my driver and got 2 new errors:

    Error 1 error MSB8020: The build tools for WindowsKernelModeDriver8.0 (Platform Toolset = 'WindowsKernelModeDriver8.0') cannot be found. To build using the WindowsKernelModeDriver8.0 build tools, please install WindowsKernelModeDriver8.0 build tools.  Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Upgrade Solution...". C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.Cpp.Platform.targets 50 5 dts9080

    The two errors are essentially the same as the one here.

    I did remove WDK 8.0 earlier because Visual Studio 2013 would not recognize the driver solution.

    Should I re-install WDK 8.0?

    Thanks,

    Brian

    Friday, September 13, 2013 6:50 PM
  • Yeah, the restore point will fail on Server, you can ignore that failure.

    VS should have prompted you to upgrade your driver project when you opened it in VS 2013 the first time. If that somehow didn't happen (or if you skipped it), you need to run the project upgrade manually.

    See http://msdn.microsoft.com/en-us/library/windows/hardware/dn265174(v=vs.85).aspx


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

    Friday, September 13, 2013 6:53 PM
  • Max,

    I am trying to perform the task in the hyperlink you posted. The command window in Visual Studio 2013 does not find the ProjectUpgradeTool.exe when I type in the command. I tried it with and without the .exe suffix to no avail.  I see the file in c:\Program Files (x86)\Windows Kits\8.1\bin subdirectory. Can I launch it outside the Visual Studio environment?

    Thanks,

    Brian

    Friday, September 13, 2013 7:10 PM
  • Yes, I believe it should work outside of the VS environment in a normal command prompt. 

    When the documentation says "open a visual studio command prompt", it means the "Developer Command Prompt for VS2013" option that is installed along with VS 2013. Easiest way to find it is by using the search charm.


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

    Friday, September 13, 2013 7:14 PM
  • Max,

    Thanks for directing me through this process.  I am now attempting to deploy my driver to my target machine. The host machine indicates it is trying to deploy the driver. I can now blue screen the target machine with my driver during deployment. I expected this as the driver is very early in the development process.

    Now I need to figure out how to get control of the driver early on so I can single step through it to see where I am going wrong.

    Thanks again for getting me this far.

    Brian

    Friday, September 13, 2013 7:37 PM
  • Awesome. 

    As for your blue screen issue, if you put a breakpoint at the very start of your driver code, enable driver deployment and hit the debug button (with the "Debugging Tools for Windows - Kernel Debugger" debugger selected), your driver should deploy to the machine and the debugger should break at driver load time.


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

    Friday, September 13, 2013 7:40 PM
  • Max,

    When I tried setting a breakpoint in DriverEntry and tried to start debugging, the host tried to provision the target again. Apparently, the host doesn't think it successfully set up the provisioning. The restore point setting failed due to my using a server as the target. The Configure Computers failed again.

    Do you know if it is possible to make the host think the provisioning was successful?

    If I press the Finish button on the Computer Configuration dialog to start debugging, I get a dialog that says "Object reference not set to an instance of an object.".

    Thanks,

    Brian

    Friday, September 13, 2013 7:58 PM
  • When provisioning completes with the restore point failure, make sure you click Next and then Finish (basically don't click Cancel or close the window with the X button). The target machine should then be added to the list of provisioned targets.

    When you click the debug button to start debugging, you must have a machine selected in the VS toolbar dropdown box (the one right next to the "Configure remote computer" button in the toolbar). Debugging will always deploy the driver remotely before starting debugging.


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

    Friday, September 13, 2013 8:21 PM
  • Max,

    I am clicking Next and then Finish when I get the Configure Computers dialog after it goes through the process of provisioning. The target machine's name is shown to the right of the Configure Remote Computers icon. I see "Debugging Tools for Windows - Kernel Debugger" with a green arrow to the left of this text. Is this what you are calling the Debug button? When I press it, I get the Configure Computers dialog. I also get it when I press F5.

    Brian

    Friday, September 13, 2013 8:35 PM
  • Did you set the driver package to be deployed to your target machine? You can do this by right-clicking on the driver package project, going to properties, Driver Install, Deployment and then select your target computer in there.

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

    Friday, September 13, 2013 8:39 PM
  • Max,

    I do have the machine name as the Target Machine Name in my driver's Package properties. When I build the driver it is deployed with no problems. It also is shown in the Configuration Properties -> Debugging remote Computer Name setting.

    My problem occurs when I try to start a debug session.

    Cheers,

    Brian

    Friday, September 13, 2013 8:44 PM
  • It seems to me like something is preventing the debugger launch because the machine hasn't been fully provisioned (because of the expected restore point failure), I'll try to repro this issue on my side using a server target OS.

    In the meantime, here's a workaround you can do to force provisioning to succeed on your server machine.

    1. Edit the CreateRestore.js script located at C:\Program Files (x86)\Windows Kits\8.1\Testing\Runtimes . You can edit it so that it does nothing and always return 0 (only leaving "WScript.Quit(0);" in the file should work for this purpose). I'd suggest running the modified script locally to make sure it works as expected.
    2. Reprovision the target machine. This should be very quick, but this time it should copy over the new CreateRestore.js script, which will force the restore point creation step to succeed. Make sure the modified script did get copied somewhere under "C:\DriverTest" on the target machine(just in case)

    Note that this will effectively disable the creation of restore points during provisioning for all target machines provisioned from your host. I suggest creating a backup of the original CreateRestore.js file, in case you need it later.


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


    Friday, September 13, 2013 9:06 PM
  • Max,

    I altered the CreateRestore.js file to only have one line: "WScript.Quit(0);" in it. I re-ran the provisioning and the file did get to the server successfully. All looks good on the host until I am finished provisioning. I am now getting a dialog stating "Object reference not set to an instance of an object." When I press the "Debugging Tools for Windows - Kernel Debugger" button, I get the computer configuration dialog again. I clicked on "Finish" to start debugging, I get the "Object reference, etc." dialog again.

    The computer configuration dialog indicates the Driver test configuration status is  Configured for driver testing.

    Cheers,

    Brian

    

    Monday, September 16, 2013 2:01 PM
  • That error dialog is weird: I've never seen that occur... I also tried provisioning a server target machine last Friday, and even though the restore point failed, I was able to continue and remote debug without any issues.

    When you moved from VS 2012 to VS 2013, did you delete the previously existing target machine from VS? You can do that from the main provisioning menu by selecting your target machine, clicking on the "Delete Computer" button and then selecting "Delete computer" (no need to remove provisioning in your case). Try to do that from VS 2013, then restart VS (just to be 100% sure that it was removed) and provision the target machine again with the same settings as those you had initially.

    As an unrelated question, what's your host OS? I know I've tried this from Win7, Win8 and Win8.1, but I'd be interested in knowing if you're using something else than those.


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

    Monday, September 16, 2013 4:11 PM
  • Max,

    I tried your procedure outlined above and had the same outcome.

    I am running Windows 7 Enterprise on my host machine (Dell Notebook) and Visual Studio Ultimate 2013 RC (Version 12.0.20827.3 DP) as my build environment.

    I am running Windows Server 2012 Standard Edition.

    It looks like it may make better sense to put Windows 8.0 on my target machine. Perhaps in all of the issues I have seen, something got changed causing my problems with Windows Server 2012.

    Thoughts?

    Thanks,

    Brian

    Monday, September 16, 2013 4:33 PM
  • Yes, at this point, I'd probably try with a different target machine (non-server one), just in case (a VM can be great for this, as you can easily revert it to a previous state). And then, if the issue still persists, I would try from a different host machine.

    It's not obvious to me what could be going wrong in your case. It might be that your host is in some kind of weird state because of the switch from VS2012 to VS2013, but I've never encountered that issue (and done this several times). Or it could simply be an issue between Win7 and Server 2012: I'd definitely suggest trying with something else than a server OS.


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

    Monday, September 16, 2013 4:42 PM
  • Max,

    Thanks for all of your effort trying to get this configuration going. I'll let you know if my new configuration works.

    Cheers,

    Brian

    Monday, September 16, 2013 4:47 PM
  • Max,

    I installed Windows 8.1 64 bit on my target machine. I installed the x64 WDK test target setup program on the target and executed it.

    I ran the computer provisioning from my host computer. As soon as I pressed the Finish button on the host side, I got the dialog "Object reference not set to an instance of an object".

    Here is my scenario:

    My target machine has two internal NICs. I connected the first NIC to our network so I could register the OS. Once everything was setup, I removed the cable from our network and connected my cable directly to the adapter of my host machine. I set a static IP address for the target and a static IP for the host. I can ping from either machine. I disable the 2nd NIC.

    I installed the x64 WDK test target setup on the target. All went fine. On my host, I do the Driver->test->configure computers operation. I choose the target machine name. I choose provision the target and automatically configure the debuggers option (the top selection).

    The process completes to the end and I press Next and then Finish. When I press Finish is where I see the dialog concerning "Object reference not set to an instance of an object.".

    I am at a loss as to what to try now other than a different target machine with one adapter. I don't know if the Visual Studio 2013 Ulitimate RC has an issue.

    Ideas?

    Brian 

    Tuesday, September 17, 2013 2:27 PM
  • I'd say I'm 95% confident that the issue is with some configuration on the host machine (maybe a disabled service?), not the target. As far as I can tell, the only thing that happens once you click on the Finish button after provisioning is saving the provisioned computer on the local machine.

    Here's a few things I'd like to know to pinpoint what the issue could be.

    • How do you access the driver provisioning menu? Do you get the bug for different access paths? For example, there's a button on the toolbar, and you can also access it from the VS menu (Driver / Test / Comfigure computers...).
    • Go to C:\Users\<yourUserName>\AppData\Local\Microsoft\DriverTest (basically %LOCALAPPDATA%\Microsoft\DriverTest). Open the MachineConfig.xml file in there: does it contain your target machine information? Can you also look at DebuggerLog.txt and see if there's anything useful in there? If either file is missing, let me know.
    • After provisioning (and clicking ok on the error dialog), is your newly added target machine selected in the target machines combo box that you see in the VS toolbar? If not, is the target machine even in the combo box?
    • If you restart VS (close all instances and then start a new one), is your target machine still in the combo box and still selected by default?

    • After provisioning, go to %APPDATA%\Microsoft\DriverTest and open the DriverTestPackageSettings.xml . Make sure your target machine's name is in there (search for the string in the file).

    • If all the above look normal, try provisioning the same target (no need to delete provisioning beforehand), but select the option to choose your debugger settings and select a different connection type than network (serial will work fine, you can use bogus data for the settings). If this leads to the same error, we know it's not an issue with the target's NICs (provisioning is always done over the network, so it should still work even with bogus debugger settings). If you do the above, be sure to reprovision with network debugging afterwards.


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


    Tuesday, September 17, 2013 4:25 PM
  • Max,

    1) I have tried the provisioning from Driver->Test->Configure Computers and using the icon to the left of the default test machine (looks like a wrench). When I perform this operation, I do not get the error dialog. At this point in time, I select the "Debugging Tools for Windows - Kernel Debugger" button. I get the Configure Computers dialog. If I press "Finish" I get the error dialog. If I press "Next", the provisioning occurs again. When this is done, I press "Finish" and I get the error dialog.

    2) Here are the contents of the MachineConfig.xml file on my host machine:

    <?xml version="1.0" encoding="utf-8"?>
    <DebugConfig LastUsedKernelMachine="" LastUsedUserMachine="" IntroSeen="true">
      <MachineConfiguration ID="cd92d368-92ed-4b9f-98ac-8a790d5e51af" 
      Name="driverdev" 
      DefaultEngine="DbgEngUser" 
      UserModeConnection="Automatic" 
      KernelModeConnection="Network" 
      UserPipe="" 
      UserPort="53902" 
      UserPassword="" 
      KernelNetPort="50516" 
      KernelNetKey="7I8XYEDRSCEB.YBAJ0FVY3IDY.LYGX0SY5UXNV.ZQMKI6GDP6EL" 
      KernelSerialBaud="115200" 
      KernelSerialUsePipe="false" 
      KernelSerialUseReconnect="false" 
      KernelSerialPort="com1" 
      KernelFirewireChannel="0" 
      KernelUSBTargetName="" 
      CurrentProvisionedState="Provisioned" 
      KernelNetHostIP="10.10.10.2" 
      KernelNetBusParams="" 
      KernelSerialTargetPort="com1" 
      KernelFirewireBusParams="" 
      KernelUSBBusParams="" />
    </DebugConfig>

    I could not find DebuggerLog.txt on either machine.

    3) My target machine's name (driverdev) is shown in the VS toolbar. I re-started VS and it showed up again with my driver solution loaded.

    4)  I could not find a file "DrivertestPackageSettings.xml" on either machine. I tried to find "Drivertest*.xml" and only found "DriverTestConfiguration.xml".

    5) I tried provisioning and chose a serial connection. The provisioning completed. When I attempt to debug, I get the configure computers dialog and I select "Finish" to start debugging and got the same error dialog.

    Thanks,

    Brian

     
    Tuesday, September 17, 2013 5:16 PM
  • You don't have the following file on your host machine: %APPDATA%\Microsoft\DriverTest\DriverTestPackageSettings.xml ? That's very weird, as this file is expected to be there by our VS extension, and is created at startup if it is not present. I believe AppData is a hidden folder, so it might not be found by search. You can simply type the path above in Windows Explorer and see if the file is there.

    If you're 100% confident that the file is not there, then that's likely the issue. That would likely mean that the extension is unable to write to that location for some reason. Does the directory even exist, and are there files in there?


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

    Tuesday, September 17, 2013 5:42 PM
  • Max,

    Thanks for clarifying how to find that file. Here are the file contents:

    <Settings xmlns="http://schemas.datacontract.org/2004/07/Microsoft.DriverKit" 
    xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
    <CurrentComputer>driverdev</CurrentComputer>
    <CurrentTest/>
    <MaxComputers>10</MaxComputers>
    <MaxResults>25</MaxResults>
    <MaxTests>15</MaxTests>
    <RecentComputers xmlns:a="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
    <a:string>driverdev</a:string><a:string>&lt;Configure Computer...&gt;</a:string>
    </RecentComputers>
    <RecentTests xmlns:a="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
    <TestSelectionPath>All Tests\Basic</TestSelectionPath>
    </Settings>

    Tuesday, September 17, 2013 5:47 PM
  • In that case, everything seems to be fine as far as your configuration goes...

    If you go the the directory of your driver package project, you should have both a packageName.vcxproj file (the VS project file) and a packageName.vcxproj.user file (which are your user settings). Do you have DbgengKernelMachineName and DbgEngRemoteMachineName set in either of those files (it should be in the vcxproj.user file)?


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

    Tuesday, September 17, 2013 6:15 PM
  • Max,

    Here are the contents of my *.vcxproj.user file:

    <?xml version="1.0" encoding="utf-8"?>

    <Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win8 Debug|x64'">
        <DbgengKernelMachineName>
        </DbgengKernelMachineName>
        <DebuggerFlavor>DbgengKernelDebugger</DebuggerFlavor>
      </PropertyGroup>
    </Project>

    In my .vcxproj file, there is nothing concerning DbgengkernelmachineName  or Dbgengremotemachinename.

    Brian

    Tuesday, September 17, 2013 6:38 PM
  • Ok, I'm pretty sure the problem is that DbgengKernelMachineName is not set in your .user file (it's totally fine if the vcxproj file doesn't contain those, as it shouldn't).

    This file is supposed to be updated when you set select the computer to use for deployment in the driver package properties menu (see http://msdn.microsoft.com/en-us/library/windows/hardware/hh454834(v=vs.85).aspx for instructions). If the vcxproj file is not being modified when you do that, then there is something very wrong that is happening.

    Is the *.vcxproj.user file set to read-only? This could happen if you've submitted it in source control, for example.

    If it's not read only, I would suggest closing VS, deleting the .user file and setting the machine to deploy to again (from the driver package properties menu, using the combo box in there). Then, "Save all" (from VS) and open the .user file to see if the DbgengKernelMachineName has been set.


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

    Tuesday, September 17, 2013 6:51 PM
  • Max,

    I checked the .user file and it was not read-only.

    I closed VS. I deleted the .user file.

    I went to the driver package properties. Under Driver Install->Deployment, it still has the target computer name. Enable deployment is still checked. I selected OK to leave the dialog.

    I selected File->Save all. I do not see a .user file.

    Is this what you suggested? Or should i actually go through the deployment process?

    Brian 

    Tuesday, September 17, 2013 7:04 PM
  • I'm sorry, it looks like the *.vcxproj.user file is saved at solution close time. Close VS (or the solution), and then you should see the changes in there.

    I just did it on my machine. If you close your driver solution, delete the *.vcxproj.user file and reopen your solution, "Enable deployment" will then be unchecked. The "EnableDeployment" property is saved in the *.vcxproj.user file, and defaults to false (or at least, should be set to false in your .vcxproj file), so it has to be set to true somewhere if it was still true for you. The same goes for your target computer name: if something was still selected, it means you probably have another project configuration file that is somehow breaking your package deployment.

    If it's not in your *vcxproj.user file, then it's definitely being set somewhere else in your project (maybe you have an old VS2012 config file in there somewhere?). An easy way to find it is to run the following command from a Windows command prompt set in your solution's root directory:

    findstr /SI /C:"DbgengKernelMachineName" *


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

    Tuesday, September 17, 2013 7:18 PM
  • Max,

    I closed VS and the *.vcxproj.user file did not show up.

    I ran findstr /SI /C:DbgengKernelMachineName" on the command line and the command hung. I ran grep from another program I have and I did not find that string.

    I am tempted to create a new KMDF project with VS 2013 RC and then populate it with my driver files. Perhaps in the progression from VS 2012 to VS 2013 RC, some subtle problems were introduced.

    Brian

    Tuesday, September 17, 2013 7:47 PM
  • Yes. I'd suggest creating a KMDF or UMDF project in VS2013 (the basic template, but not the empty one) and try deploying that to see what happens.

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

    Tuesday, September 17, 2013 7:49 PM
  • Max,
    I created a simple KMDF driver project from the template. I have not changed any source code. I made the project for x64 targets.

    I checked everything for deployment to my target machine.

    I set a breakpoint in DriverEntry and built the driver. The driver builds successfully and is deployed to my target machine.

    When I press the Debugging Tools for Windows-Kernel Debugger button, I get a dialog with "This project is out of date. Would you like to build it?". I say yes and it goes through the deployment process again.

    Right away, I get a dialog "Windows Debugging Extension for Visual Studio Could not start debug session, error 80004005: Unspecified error"

    Thoughts?
    Brian
    Wednesday, September 18, 2013 3:07 PM
  • Just for your information, the "Debug" button for a driver package will build, deploy and then debug your driver, so there's no need to deploy separately.

    Is your host machine running Visual Studio as administrator on Windows 7? If you are logged in as the "Administrator" user account in Windows 7, this is likely the case. If so, there's a known bug in the debuggers shipped with WDK 8 and 8.1 related to that scenario: see http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/d9e4bf00-7efe-4b8a-9ead-ec1a39814e6c/enable-to-correcltly-stop-kmdf-network-debugging for more details.

    Make sure you use a non-administrator VS and that no instances of ntsd are running before you start debugging (Task Manager can help with that).

    If that is not your issue, I would suggest trying to remote debug through WinDBG and see if that works: it not, it will likely give you a better error message.


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

    Wednesday, September 18, 2013 5:29 PM
  • Max,

    I took off my Administrator privileges from my login and re-booted. 

    I rebuilt the driver and i am now getting a "No certificates were found that met all the given criteria" error.

    Is there a quick way to solve this issue?

    Thanks,

    Brian

    Wednesday, September 18, 2013 7:08 PM
  • That's a SignTool error. Either turn off driver signing, or select a valid certificate. This is all accessible from the driver package properties, in the "Driver Signing" submenu.

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

    Wednesday, September 18, 2013 7:12 PM
  • Max,

    Turning off driver signing did not work. I tried to select a certificate for test and create a test certificate and I still get this error.

    Brian

    Wednesday, September 18, 2013 7:25 PM
  • To be clear: your account should have administrative rights (or at least, I'd suggest you do), but on Windows 7, it should not be the built-in "Administrator" account (so basically, if your account name is not "Administrator", you're fine), so that VS is not run with executed privileges by default.

    As far as I know, the SignTool won't get called if you set driver signing to Off, so it's surprising that you would get this error if you turned it off. I'd suggest trying to call the SignTool separately to see if you still get the error. You can also look on the web for that error, as I believe it's a "common" SignTool error.


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

    Wednesday, September 18, 2013 7:34 PM
  • Max,

    I turned off Administrative rights to my account and that is what fouled up the Signtool step. I'll keep plugging along. I haven't tried WinDBG yet. That may be the next step.

    Cheers,

    Brian

    Wednesday, September 18, 2013 8:42 PM
  • Max,

    I discovered that I had several instances of ntsd.exe running on my host. I killed them all and started everything over.

    In the Debugger Immediate Window in Visual Studio, I am seeing a "Fail" for the Driver Removal (x64) (possible reboot) step in the Driver Installation summary. Right above this, there is a line indicating  "Error generating test results report: An error occurred while loading document 'C:\Users\MOO59629\AppData\Roaming\Microsoft\DriverTest\TestRepository\Results\Default_Driver_Package_Installation_Task_(possible_reboot)_00020.wtl'. See InnerException for a complete description of the error.

    Where can I find the InnerException information?

    On the target machine, the .wtl file corrsponding to this in the \Logs subdirectory,  has the following text:

    <Msg 
    UserText="WDTF_DRIVER_SETUP_SYSTEM  :          C:\Windows\inf\oem6.inf" CA="4684528" LA="4684616" >
    <Data>
    <WexTraceInfo ThreadId="1224" ProcessId="2056" TimeStamp="269803740"/>
    </Data> <rti id="2455036156" />
    <ctx id="1665270105" />
    </Msg>
    <Error 
    File="" 
    Line="-1" 
    ErrCode="0x0" 
    ErrType="" 
    ErrorText="Error 0x00000000" 
    UserText="WDTF_DRIVER_SETUP_SYSTEM  : DriverSetupSystem::RemoveDriverPackage() error - cannot remove driver package that is not imported HRESULT=0x80004005" CA="4881557" LA="4881688" >
    <Data>
    <WexTraceInfo ThreadId="1224" ProcessId="2056" TimeStamp="270041937"/>
    </Data> <rti id="2455036156" />
    <ctx id="1665270105" />
    </Error>

    and

    <Msg 
    UserText="COM failure occurred. HRESULT: 0x80004005." CA="5235608" LA="5235691" >
    <Data>

    Can you clarify what this means and how I can get past this?

    Thanks,

    Brian

    Thursday, September 19, 2013 2:23 PM
  • Yes, the multiple ntsd.exe instances issue is likely related to the Win7 bug I referred to, see my link above.

    I don't think you can access the InnerException without having a debugger attached to Visual Studio when the problem occurs. It's weird though that your host machine would be missing that file: I'm guessing something went wrong while retrieving the target's log file. Usually, once the target's .wtl files are retrieved, the host creates a readable HTML report out of the WTL result files.

    In your case, this says that the removal of the driver package failed because the specified driver was not installed on the target machine. This usually happens if you've enabled driver removal before deployment, but never deployed the driver to the target before. A failure for the driver removal step is expected in this case, and shouldn't block the driver deployment.


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

    Thursday, September 19, 2013 7:35 PM
  • Max,

    I decided to comment out the hardware access code that was in my driver that was causing the target machine to blue screen. After multiple attempts to provision, i was finally able to get the Driver installation Summary to pass:

    [14:00:05:854]: Driver Installation summary:
    [14:00:05:856]:   Driver Removal (x64) (possible reboot): Pass
    [14:00:05:858]:   Driver Preparation (x64) (possible reboot): Pass
    [14:00:05:859]:   Default Driver Package Installation Task (possible reboot): Pass
    [14:00:05:860]:   Driver Post Install Actions (x64) (possible reboot): Pass

    Now, the Debugger Immediate Window is sitting there with "Debuggee is running..." at the bottom.

    I am not sure what to do next. I looked in the Tools menu for a way to attach to a remote process. This option does not exist. Do I use Windbg on the host computer to get control of the driver on the target by disabling, setting a breakpoint, and then reenabling the driver? Or is this built into Visual Studio?

    Thanks,

    Brian

    Thursday, September 19, 2013 7:37 PM
  • If it says that the debuggee is running, usually it means you're attached to the target machine, though I'd suggest looking in the debugger window that popped up in VS, to make sure that the connection was successful. There should usually be a message that looks like "Connected to ...."

    WinDbg is integrated into Visual Studio, so you should be able to use it from VS. For example, the break button will break into your target machine, and any breakpoint that you put on your code should work. There should no need to start an external WinDbg.

    If, for some reason, the debugging doesn't work from VS (for example, clicking the break button does nothing), then I'd suggest trying to connect to your target from WinDbg with the debugger settings you specified in VS when you provisioned the target. This should tell you why there was an error connecting to the target.


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

    Thursday, September 19, 2013 7:43 PM
  • The Break-All button on the host side does not seem to do anything. 

    I have not used WinDbg before so bear with me. I fired up the x64 version on the host and selected Kernel Debug. I placed the Port Number value that appears in the computer configuration dialog and I hand entered the Key that appears on that same dialog. (Is there anyplace I can just copy that key?).

    When I tried to connect I got a Winsock error. 

    Thoughts?

    Thanks,

    Brian


    Thursday, September 19, 2013 8:31 PM
  • Seems to me like you did the right steps, but I am in no way a WinDbg expert. I'd suggest you look at the WinDbg documentation (see http://msdn.microsoft.com/en-us/library/windows/hardware/hh439346(v=vs.85).aspx for a starting point).

    If you're having troubles connecting even with WinDbg, then it's a debugger problem. There's a Debugger forum on MSDN that might contain helpful information, and the MSDN documentation on debuggers can also help you.


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

    Thursday, September 19, 2013 8:39 PM
  • Max,

    I am trying to debug why the Debugger Immediate window shows the Driver Installation summary with everything passing and then just sits there. Communication between the host and target have stopped.

    Should msvsmon.exe be running on the target at this point?

    Brian

    Friday, September 20, 2013 2:26 PM
  • The Debugger Immediate window contains the output for both the driver deployment process and the WinDbg integration. If, after deployment has ended, it's just standing there, it usually means that the debugger is waiting for your action (for example, press the break button) or that the remote debugger connection failed (which you can validate by using WinDbg with the same settings).

    If you scroll up in the debugger immediate window, you should see something like:

    Microsoft (R) Windows Debugger Version 6.3.9600.0 AMD64

    Copyright (c) Microsoft Corporation. All rights reserved.

    <MACHINE-NAME> (npipe WinIDE_01CEB627A9C9B510) connected at Fri Sep 20 10:34:31 2013

    Microsoft (R) Windows Debugger Version 6.3.9600.0 AMD64

    Copyright (c) Microsoft Corporation. All rights reserved.

    Using NET for debugging

    Opened WinSock 2.0

    Waiting to reconnect...

    Connected to target IP_ADDRESS on port 50019 on local IP HOST_IP_ADDRESS.

    If you don't see a "connected to target" message, than there's something going wrong (you might see an error message in there as well), and you should try connecting with WinDbg itself to figure out what's going wrong.

    msvsmon does not have to be running on the target at all, as it is not used by the windows debuggers. The driver debugging experience does not use msvsmon: it uses the Windows Debuggers DLLs and binaries.


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

    Friday, September 20, 2013 5:39 PM
  • Max,

    I re-installed VS Pro 2013 RC and WDK 8.1. 

    The Debugger Immediate Window shows the Kernel Debugger connection is established.

    Here are the bottom lines of the window:

    [13:25:42:141]: Driver Installation summary:
    [13:25:42:142]:   Driver Removal (x64) (possible reboot): Pass
    [13:25:42:145]:   Driver Preparation (x64) (possible reboot): Pass
    [13:25:42:147]:   Default Driver Package Installation Task (possible reboot): Pass
    [13:25:42:149]:   Driver Post Install Actions (x64) (possible reboot): Pass

    I have set breakpoints at various places in my driver and I have not hit any.

    I really want to get control in my driver and single-step where I start accessing hardware. I have conditionally-compiled out my hardware accesses because I was killing the box. 

    I feel I am so close.

    What am I missing or what do I do now?

    Thanks,

    Brian

    Wednesday, September 25, 2013 5:35 PM
  • I just tried Break-All and I got control.

    Unfortunately, The code is all in Assembly language. 

    I have filled in an environment variable _NT_SYMBOL_PATH to my source code. Is there a way to re-start the driver and have the debugger hit the breakpoints I have set?

    Thanks,

    Brian

    Wednesday, September 25, 2013 5:48 PM
  • I tried using Device manager on the target machine and disabled and then enabled my device. I hit a break-point!

    Going to have to play around to see how to put in a failing driver and see why it is failing.

    Cheers,

    Brian

    Wednesday, September 25, 2013 5:51 PM
  • At this point, it seems like you have the VS-integration working, so it's mostly a matter of playing around with your driver and the remote debugger. The VS integration is really just a wrapper on top of WinDBG, so any WinDbg documentation is also applicable.

    If you have further questions related on how to debug your drivers, I'd suggest starting a new thread, as this one is getting huge.

    Good to know you got it to work :)


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

    Wednesday, September 25, 2013 5:54 PM
  • Thank you for your help.

    Brian

    Wednesday, September 25, 2013 6:10 PM
  • I have the same problem as stated in the title of this thread. I am using Visual Studio 13 and WDK 8.1 on my host. My target is running windows 7 x64. I applied your answer "on the target machine, add "Authenticated Users" with modify rights on the C:\DriverTest directory tree. Then try provisioning again". The problem persists after applying this answer.

    In your comment you state that the file C:\DriverTest\Run\WexLogFileOutput\VerifierSettings.txt is created but I only find a file called 000001_~LogDriverVerifierSettings_DriverVerifierSettings.txt in the C:\DriverTest\Run\WexLogFileOutput directory. I do not know if it matters but the file 000001_~LogDriverVerifierSettings_DriverVerifierSettings.txt only contains three lines with a zero character on each line.

    Any suggestings on how to solve this "Driver verifier settings file was not found" error would be helpful.

    Thanks

    Friday, June 20, 2014 2:53 PM
  • I'm having the same problem. What is weird for me is if I try and deploy the echoemdfdriver, it works, but with my own umdf driver it fails with the "UMDF verifier settings file was not found". In the Gathering_UMDF_verifier_settings_*.wtml file, it actually states "Succesfully gathered UMDF verifier settings".
    Thursday, October 27, 2016 4:17 PM