To build my driver i used VisualDDK in visual studio 2008. In the beginning i start debugging using my computer and virtualBox machine but when i launch the debugging process in visual studio, my virtual machine did not show me the external ip address(normally should show me 192.168.1.102 and 10.0.1.15 in DDKLauncherMonitor but it show me only 10.0.1.15 ).
I stopped using virtual machine and i decide to use real computer. In the second computer i launched DDKLauncherMonitor. And i start debugging from my first computer. I received Udp package in my second machine and also the driver.sys. But when i tried to load the driver from visual studio(First computer) nothing work. Plus this, in the second machine tell me "Windows required digitally signed driver".
There is same one meet this kind of problem and he/she can help.
Can you go into more details when you say "nothing works"? It's possible that your debugger is not set up properly.
This is kind of a pseudo-answer since I'm not overly aware of VisualDDK, but have you considered trying the standard Microsoft debugging tools like WinDbg? If you can acquire Visual Studio 2012 or 2013 Preview, all of the build and debug tools are integrated into the IDE and you will get full support from Microsoft with any problems you may encounter.
As for your second issue, it sounds like you're building a driver and not signing it. Is your target PC 64-bit? What operating system is it? The 64-bit Windows platform requires signed drivers for installation, but this can be disabled.
You can disable the driver signing requirement using the F8 menu when booting your PC; this should fix your "digitally signed driver required" problem, but needs to be done for each reboot.
Another option would be to add a post-build step or some sort of scripted execution of the Microsoft signing tools (Inf2cat, SignTool) to sign your driver with your company's certificate.
Related
I'm developing a Windows driver using Visual Studio + WDK, but i'm not able to test it.
There's a article about it, that says:
A test computer (or computers). The test computer must be on the same
network as the computer that you are using for development.
But I don't have another computer.
Does anyone knows a way to test using the same computer that i'm using to develop (local debuggin)?
I'm using:
Microsoft Visual Studio Community 2017
Version 15.5.2
VisualStudio.15.Release/15.5.2+27130.2010
Microsoft .NET Framework
Version 4.7.02558
Windows Driver Kit 10.0.16292.1001
Thank you!
You can use a Virtual Machine, I do this frequently but sometimes I prefer to use a physical machine. The Virtual Machine method will use a named pipe for Inter-Process Communication (IPC) between Visual Studio (the WinDbg engine is used) and the Virtual Machine environment; you'll preferably want to use VMWare but I have not used VirtualBox for this before.
See the following article please:
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/attaching-to-a-virtual-machine--kernel-mode-
You cannot however debug your kernel-mode software while it is active on your actual Host environment; testing kernel-mode software on your Host environment until you are certain it will go well is a bad idea anyway because data corruption is caused by BSOD crashes so if a BSOD crash occurs, you can lose sensitive and important data unexpectedly.
Is there anyway I can test/debug Window drivers locally? That way I don't need a separate computer or to install a VM.
I followed these instructions: http://msdn.microsoft.com/en-us/library/windows/hardware/ff553382(v=vs.85).aspx
But I can't get past the welcome screen with bcdedit /debug on enabled. My computer just hangs there.
I am using Visual Studio 2013 and the Windows 8.1 Driver Kit
In my opinion, local kernel debugging is next to worthless.
Even if it wasn't worthless, targeting a separate machine (virtual or physical) is the way to go, as kernel mode drivers under development can (and most likely will) destabilize the target machine until they're complete - something that you likely don't want happening on your development machine.
I've written a Windows driver sample (WDM) with Visual Studio but I'm encountering issues when trying to debug it. The target is running in a Virtual Machine (VMware)
I've followed the documentation (http://msdn.microsoft.com/en-us/library/windows/hardware/hh698272(v=vs.85).aspx) to configure everything.
It's compiling fine but there are problems when debugging.
I have tried various configurations and have different problems on each.
Visual Studio 2013 Preview on Win7 (host) / Win8.1 Preview (target) - VMware
It seems the debugger isn't working properly. Indeed it's like if nothing was loaded, the Modules Window is empty, when I click on "Break all" nothing is happening. As you can see in the logs, the debugger session isn't created.
Screenshot:
Logs: http://pastebin.com/DfVzGR4Z
Visual Studio 2012 on Win7 (host) / Win8 (target) - VMware
It's working correctly at the first try but if I stop the debugger to modify the driver, it'll freeze the VM. I'll then have to restart the VM, Visual Studio and kill the process ntkd.exe because otherwise I have these errors:
Failure to create process instance prevents debugging
Unable to start (null), Error 80004005. (Unspecified error)
Followed by a crash of VS (Event Name: CLR20r3)
I've tried with other samples downloaded from the MSDN but it's the same problem.
I've been stuck on these issues for weeks and I'm starting to desperate, so any help would be appreciate. I haven't tried WinDDK but since VS has everything needed, I don't see why I couldn't use it normally.
I recommend to forget using Visual Studio for driver development/debugging because, on my opinion, is not solid enough.
But targetting the debugging process, it is better to install VisualDDK and then launch vmmon/vmmon64.
In the installed application you will find a folder named "target" with an application named DDKLaunchMonitor.exe, install it in the virtual machine (it will create a boot menu option to activate kernel debugging)
When you want to debug your driver, launch vmmon, activate the option to launch windbg at vm startup, start your vm and when windows boots it will load windbg and attach to the vm.
The install your driver as desired and learn windbg.
I know this answer does not solve you problem with VS but using windbg directly is faster and better.
I was having a similar problem with: Visual Studio 2015 Community Edition, Windows 10 host, Windows 10 target, VirtualBox with host only network.
Provisioning and remote driver deployment worked, but the debugger would not connect.
Edit: In the last step of provisioning in VS2015 the Host IP can be selected. The manual method below is an alternative.
The manual setup guide for kernel mode debugging says to run the following:
bcdedit /debug on
bcdedit /dbgsettings net hostip:w.x.y.z port:n
Visual Studio automatically runs these during the provisioning process. Notice the hostip parameter - this has to be the address of the connecting machine (the one with the debugger) on the interface it uses to connect to the target. Visual Studio may set this incorrectly if you have multiple network interfaces. In my case the VirtualBox host only network created the extra network interface.
Provision the target machine in VS, if you haven't already. Then run the two bcdedit commands above and reboot the target machine. After this, the debugger should connect properly.
I came across the same problem. The windbg connection is hang. I found there is something wrong in my configuration for Kernel mode debugger settings( Visual studio 2012 Driver->test->Configuration). I set the port simply com1. Actually, it should be \.\pipe\com_1.Then it works
In your case, there maybe other configuration problems. You can check through the points on webpage http://www.codeproject.com/Tips/545835/Kernel-Mode-Debugging-in-a-VM-using-Visual-Studio.
I am trying to run my visual studio (2010) C++ project on an old Windows XP machine that is running VS2010. However, when I run it, I get the error listed in the title of this question. Why is this, and how can I fix it?
Same error was throwing for me when I had Silverlight debugger enabled. To resolve this issue
Open project properties
Under web tab look for Debuggers
Remove the tick mark on "Silverlight"
In general, a debugger should be the same bitness as the debuggee (or at least it must be able to understand the architecture of the target). In any common siutation, an x86-based debugger will not be able to debug an x64 application.
The Visual Studio documentation says:
To debug a 64-bit application that is running on a remote computer,
you need to install the 64-bit remote debugger on the remote computer.
The 64-bit remote debugger is available on the last disc of your
Visual Studio installation set.
I am trying to remote debug my application in VMware workstation 7 and Visual studio 2010 ultimate. I habe several images (win 7 ultimate,vista,etc).
I am following this tutorial: http://kristofmattei.be/2010/01/20/debugging-applications-in-virtual-machines-with-vmware-workstation-7-and-visual-studio-2008-sp1-2/
Whenever I try to start msvsmon.exe on the remote computer it will say :
"The visual studio remote debugger does not support this edition of windows"
tried it with win 7 ultimate, vista premium and xp home, same situation.
Could someone help me out here?
Thanks!
The error message "The visual studio remote debugger does not support this edition of windows" appears because the remote debugger tries to use Windows Authentication by default, and this is only supported in the "Pro" versions of Windows, and up.
However, the remote debugger does work with the "Home" versions of Windows, you just have to tell it not to use authentication via the command line.
(Why it doesn't let you do this after launching it without any arguments, why the error message is so misleading (and contradicts the official list of supported OS), and why there is so little info about this on the web, I don't know. :))
To launch it, run this:
msvsmon.exe /noauth /nosecuritywarn
Of course, this launches it in the lowest security mode, so you'd only want to do this on a secure network. (But that's usually the mode one ends up using msvcmon in anyway, as the other mode is an even bigger PITA to set up than it is normally. Very useful tool, but really could use some streamlining.)
No need to use VMWare features.
Inside the guest VM run the version of msvsmon that came with your copy of visual studio 2010 (A setup package for just the remote deubgging stuff can be found on the disc/image) (use x86 if debugging a 32-bit process or x64 if debugging 64-bit one ,Itanium if you need to laugh).
through the msvsmon GUI disable authentication and select allow any user to connect.
disable the firewall in the VM.
on the host machine you should be running visual studio 2010, under the debug dropdown select "attach to process..." and then on the window that pops up select remote from the dropdown that should say local or something initially, enter the IP address (should be private network IP i.e. 10.1.?.?) of the guest VM, alternatively use the server name displayed by the msvsmon GUI. You should get the process list for the guest and should only attach to any process that matches the version of msvsmon you ran (x86 or 64 ...or Itanium laugh).
NOTE: These are basic instructions to show you it definitely works but these instructions will only work for native code since managed requires a secure connection.
If you are debugging a .NET app using the VMWare VS Plugin and are getting a "file not found" type of error...make sure you have the .NET runtime installed! :)
Like a moron, I set up a fresh XP VM and forgot to install the .NET runtime and wasted a good day trying to get the VMWare VS Plug-In to work!
VSID is not supported by visual studio2010 http://communities.vmware.com/thread/282407