Issue with driver deployment and debug

jguo5258

Alright, two issues:

Whenever i try deploying my driver on visual studio to my virtualbox, there is an error: unable to connect to the test target computer. This shouldn’t be happening, because I am able to connect through windbg. My network between my virtual box and host is NAT. Driver deploy always fails

Also, the windbg connects, but nothing shows when the windbg kernel debug is connected. Is this supposed to happen,or am I missing something? How would I fix this?

Is there an easy way to avoid all the visual studio bullshit? I’ve heard about kdfiles

Peter_Viscarola_(OSR)

visual studio bullshit

The pretty much sums it up.

The easiest way to fix this is to NOT use Visual Studio to deploy your driver, and to NOT use the kernel debugger through Visual Studio. Why? Because, as you have seen, a lot of times it does not work, and when it doesn’t work it’s almost impossible to figure out why.

Instead of “deploy” just copy your driver to your test system. Disable the driver (using device manager if you wish), Copy the updated executable to \windows\system32\drivers, and Enable the driver. Alternatively, you can use .kdfiles instead of doing the copy. Once the KDFILES mapping is set up, just disabling and enabling the driver will cause the new version to load. Look at .kdfiles with the -m switch, and save yourself the considerable hassle of getting the format of the stupid mapping file to work properly (thank you, Mr. Tippet).

Instead of debugging through Visual Studio, just directly run WinDbg. It’s installed as part of the WDK... or use the “attractive” new version you can download from the Windows Store. Follow the instructions in the MSDN docs on how to manually attach the kernel debugger over the network, including enabling debugging on the test machine.

I promise, if you leave the use of VS for deploy and debug behind, you will not regret it. They should put Lasciate ogne speranza voi ch'intrate in the title of the dialog box when you go to enable deployment. It’s an entirely random and most often painful and futile experience, every time I’ve tried it.

Peter

jguo5258

a

jguo5258

@Peter_Viscarola_(OSR) said:

visual studio bullshit

The pretty much sums it up.

The easiest way to fix this is to NOT use Visual Studio to deploy your driver, and to NOT use the kernel debugger through Visual Studio. Why? Because, as you have seen, a lot of times it does not work, and when it doesn’t work it’s almost impossible to figure out why.

Instead of “deploy” just copy your driver to your test system. Disable the driver (using device manager if you wish), Copy the updated executable to \windows\system32\drivers, and Enable the driver. Alternatively, you can use .kdfiles instead of doing the copy. Once the KDFILES mapping is set up, just disabling and enabling the driver will cause the new version to load. Look at .kdfiles with the -m switch, and save yourself the considerable hassle of getting the format of the stupid mapping file to work properly (thank you, Mr. Tippet).

Instead of debugging through Visual Studio, just directly run WinDbg. It’s installed as part of the WDK... or use the “attractive” new version you can download from the Windows Store. Follow the instructions in the MSDN docs on how to manually attach the kernel debugger over the network, including enabling debugging on the test machine.

I promise, if you leave the use of VS for deploy and debug behind, you will not regret it. They should put Lasciate ogne speranza voi ch'intrate in the title of the dialog box when you go to enable deployment. It’s an entirely random and most often painful and futile experience, every time I’ve tried it.

Peter

how would i build on release to generate the required driver files?

Peter_Viscarola_(OSR)

how would i build on release to generate the required driver files?

I'm sorry, I don't understand the question. Can you explain further, please?

Peter