Hi, many user of c++ development but almost zero with driver development.
Struggling with getting a working dev environment.
The problem I’m having is trying to auto deploy and debug.
The error I’m getting is
Failure to create process instance prevents debugging.
Both machines are running Windows 10 in VMWare.
Visual Studio 2015 with all updates.
The target has the Kernel debugger nic with an IPV4 address
I can ping the target from the dev machine.
What should I be looking for please?
Try to provision the target machinbe from Visual Studio.
Yes, I have done that - went thru a list of things, setting up new user account, installing nic etc.
All seemed to work ok.
On Mon, Apr 24, 2017 at 3:20 PM, wrote:
> Yes, I have done that - went thru a list of things, setting up new user account, installing nic etc.
> All seemed to work ok.
You didn’t install VS2015 on both computers, did you?
No, just my dev machine - it also has VS2017 on it too.
What is VS trying to do when it give me the error Failed to Create Process Instance?
Are there any logs or steps I can do individually to find why it’s failing?
I have checked firewall and that is open.
Thanks,
In Visual Studio, you have different verbosity levels. By default the minimal one is used. Try to use a higher one to see if you can get more informations. The exec that is being launched remotely for instance.
Not any further with this … After getting VS2015 to provision my target machine I can manually start a WinDbg session from the host and break into the target machine.
The issue is with VS2015 (failing to) launch some process when I press F5 (the target machine is selected)
I might add that the same error occurs when I try to attach the target machine using the Kernel Debugger from VS2015 - In the attach dialog VS does show me the kernel process as an option to attach.
By the way this is trying to work with the latest SDK and DDK 1703
xxxxx@oaklodge.com wrote:
Not any further with this … After getting VS2015 to provision my target machine I can manually start a WinDbg session from the host and break into the target machine.
Without intending to offer any editorial comment on the automated
solution, I will say that your second sentence describes the way most of
us grizzled old veterans do our development and debugging.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Once you will have a working environment you will notice that kernel debugging from VS or WinDbg is the same. This is called « Debugging tools for Windows ».
I have tried and the deployement failed because a communication was closed between the host and target.
There is a service running on the target called « WDK Remote Communication Service ». This service was not running when I checked so I restarted it and made a new deployement. It worked.
My guess is that the service crashed. This is comfirmed by the system log. There are also « access denied » related entries in the system log.
Strange – here I don’t see any relevant entries in the system log or application log on either the host or the target.
The WDK Remote Communication Service is running.
Scratching head …
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: 25 April 2017 19:53
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] New to driver dev
I have tried and the deployement failed because a communication was closed between the host and target.
There is a service running on the target called « WDK Remote Communication Service ». This service was not running when I checked so I restarted it and made a new deployement. It worked.
My guess is that the service crashed. This is comfirmed by the system log. There are also « access denied » related entries in the system log.
—
NTDEV is sponsored by OSR
Visit the list online at: http:
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:
To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:>
In VS men, choose Driver > Test > Test Group Explorer …
Select the html report. For me it is named Driver Installation 00000.html.
Last time I kernel debugged a VMware target you had to connect over a pipe from the host (the host was the actual PC, not sure VMware to WMware can be debugged).
This was with Windbg. Not sure if VS works with VMware, I never tried it.
But can I echo Tim here, speaking for myself I only ever use WIndbg, and in fact once you get used to it you will probably prefer it to VS. It is very powerfull debugger.
Thanks for the suggestions - clearly I have a lot to learn here …
Other than Microsoft what do people recommend as learning resources?
Are the good books, related to Windows 10 for developing drivers and understanding?
Thanks.
Are you using a COM port for the connection ? If so, change to network debugging.
I dont know if VMware suports host to targetVM network debugging, but because they are on the same machine the ‘COM port and named pipe’ method is very quick.
Given the ability to snapshot a VM it is actually a very good way to debug, takes up less desk space too.
Given that I can manually launch WinDbg from the host vm machine over a virtual network to the target, also vm machine - I think we can assume that I can debug inside vmware over network.
So it seems the issue is only with VS 2015 …
Open to video or book suggestions please for driver development 
>So it seems the issue is only with VS 2015 …
It may be of course but I don’t think it is because it is working very well for me.
Open to video or book suggestions please for driver development
MSDN is the first place to look for documentation. For instance, setting up and provisioning a virtual machine for kernel dev with a COM port is well documented in MSDN.
https://msdn.microsoft.com/en-us/library/windows/hardware/hh439378(v=vs.85).aspx