Test Windows driver in Visual Studio (local) - windows

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.

Related

Offline Kernel Mode Driver debugging with WinDBG and VMware - What symbol files am I missing?

As a part of a project I am learning how to write Kernel Drivers for windows.
I have setup the following environment:
My Virtual target machine is Windows 7 Sp1 x86 - Running on VMware Workstation.
My host machine is Windows 7 Running windbg to remote debug the target's kernel (I used debugging via virtual serial cable and a named pipe since net debugging is available only from windows 8)
I installed the latest WDK and visual studio 2017 community.
I've written and compiled the driver as in the Microsoft docs.
I copied the sys file generated under the Debug folder to the target machine and installed the driver with Osrloader.
When I hit start service the computer freezes and the system crashes.
Questions
The computer is offline (Hence no connection to the windows Symbol Server), could the missing symbols cause such errors? If so how should I use the syschk tool to solve this?
*Please note I did not install any symbols yet.

Debugging driver locally

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.

KMDF driver building using VisualDDK and Visual studio 2008

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.

Remote debugging in visual studio: remote debugger does not support this edition of windows

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

VMWARE: For installing Visual Studio 2010 and connecting to it remotely?

I am trying to find a solution for installing Visual Studio 2010 (VMWARE) and connecting to it remotely so that both i can use the pc and the receiver can monitor what i am doing.
There seems to be so many different solutions for VMWARE and i am little of which will work.
It would be ideal if it was free of charge, i notice the "VMWARE PLAYER" is - but i think is only to run virtual machines???
If anybody has had any success of running VMWARE with visual studio 2010 i would look to hear your comments or any advice
Thanks
EDIT
TO clarify, i am looking to run visual studio 2010 in VM.
In order to run VS2010 in VM you will need:
VMWare Server 2.0
Licenced operating system
VS2010
Follow those steps:
Install VMWare server on the physical host
Create a new virtual machine
Install operating system on your virtual machine
Install VS2010 + any other software you need for development
Connect your VM to internet so it can be connected to from internet (open necessary firewall ports)
On a side note: why do you want the receiver to have access to your development environment in the first place? Won't it suffice to give him access to your deliverables only? If you are developing a web site - publish it and give him access. For desktop apps give him the link to a site where you can dump your nightly builds...
I agree with Jakub, but you could also use ESXi on a system do the same thing and have for a few trade shows I would do the following
1) VMware ESXi, use 4.01 located at VMware vSPhere Hypervisor ESXi
2) Use Microsoft Windows 2008, you can be granted a 60 day license for testing.
3) Install Microsoft VS2010 (in my case it was Microsoft VS2008, its all our group uses.
The only issues I have found are when installing Visual Studio 2008, the OS detection might cause a few issues. VS2010 should be able to correctly detect the OS you are using.
The other testing bed the developers I support use are based around the same thing, but use Xen for the hypervisor. We have found on long haul networks using tunnels, VMware ESXi's remote console sessions can be crazy and produced odd graphical draws and even latency.
Good luck with Visual Studio 2010. And I hope your teams work out.

Resources