I have setup a hyper v virtual machine and configured it as a target machine,
I followed this guide:
https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/attaching-to-a-virtual-machine--kernel-mode-
Then I ran the Windbg preview with the appropriate COM port settings, though it says that the debuggee is running it won't break into it.
Every time I try to break into it, it says in the logs that a function has been cancled, don't really know how to go about it.
Here's the error:
DbgX.Services.dll : System.Threading.Tasks.TaskCanceledException: A task was canceled.
at DbgX.Debugger.TargetOptions.KernelConnectionHandler.ProcessLaunchOptionAsync(KernelConnectionOption option, EngineOptions engineOptions)
at DbgX.Debugger.TargetOptions.LaunchTargetOptionHandler`1.ProcessOptionAsync(T option, EngineOptions engineOptions)
at DbgX.Services.CommandLine.ConfiguredTargetManager.LaunchTargetAsync(IDbgTargetConfiguration target)
at DbgXUI.Dialogs.RecentTargets.RecentTargetsViewModel.LaunchCurrentTargetAsync()
at DbgX.Services.Utilities.TaskExtensionMethods.AwaitAndLog(Task task, String taskName)
Before I downloaded hyper v vm, I tried using othe vms such as Virtual box and VMware though I came across the same issue, which implies that the problem is probably with the debugger itself.
Related
I've been playing with VirtualBox implementations of Xubuntu. I'm learning provisioning test boxes with content using both VBoxManage and Vagrant. Unfortunately my boxes work very erratically. I'd like to enable the debug mode in VirtualBox to better understand why the boxes sometimes freeze up.
Current top menu: VirtualBox VM / Machine / View / Input / Devices / Window / Help. I'd like to be able to get to the / Debug / top menu with its selection of Statistics / Command Line / Logging / Show Log as displayed in the VirtualBox Graphical User Input (GUI) tool, [select Virtual Machine --> Settings --> User Interface.]
As I understand it, I'm looking for the Built In Debugger. I've found the instructions, but they don't make sense to me.
The debugger can be enabled in three ways:
Start the VM directly using VirtualBox --startvm, with an additional
--dbg, --debug, or --debug-command-line argument.
Set the VBOX_GUI_DBG_ENABLED or VBOX_GUI_DBG_AUTO_SHOW environment
variable to true before launching the VirtualBox process. Setting
these variables (only their presence is checked) is effective even
when the first VirtualBox process is the VM selector window. VMs
subsequently launched from the selector will have the debugger
enabled.
Set the GUI/Dbg/Enabled extra data item to true before launching the
VM. This can be set globally or on a per VM basis.
I know how to start my virtual boxes in two ways. 1) Open the Virtual Box GUI, click on the machine of interest, then start it up. 2) Start the box up from the folder that contains my custom Vagrantfile, then $ vagrant up.
Its not clear to me from the above link on Virtualbox, how to set up vagrant or VBoxManage or VirtualBox GUI to start up a box with Debug mode enabled (or better yet, enable Debug mode when building a custom box...). I can't believe someone built up a nice GUI then omit the chance to implement Debug into the tool.
Note: I'm using MacOS for my host; I've had best luck using bstoots/xubuntu-16.04-desktop-amd64 as the base for my guest virtual machine box. Anybody been here before? Tips and hints as to how to start a box with debug enabled? Many thanks.
So I tried few more things (Virtual Box 5.2.20 r125813 on 64-bit Win7 Enterprise).
Method 3'' (per machine ExtraDataItem: does NOT do anything, even does not add 'Debug' menu to the VM window)
Method 3' (global ExtraDataItem): adds 'Debug' menu to the VM windows but does not break at the VM start (VM is just running, you can open the debug console and stop it but then of course we are deep into the boot process, or after...). But it could be useful ... no harm of having 'Debug' as a default.
Method 1: Works BUT not as described, even in the VBox own User manual is confused, page 261 describes the options WRONG. However the chapter 8 gives some ideas, here we go:
you can add the environment variables to the command line:
C:\Program Files\Oracle\VirtualBox>vboxmanage startvm "SomeVM" -E VBOX_GUI_DBG_AUTO_SHOW=true -E VBOX_GUI_DBG_ENABLED=true
will show the 'Debug' menu, open the debug window and load the VM halted at the reset vector
VBOX_GUI_DBG_ENABLED=true
alone will just add 'Debug' to the VM's window (the VM will run)
VBOX_GUI_DBG_AUTO_SHOW=true
alone will load VM halted but no 'Debug' menu so really nothing to do ... (however this can be paired with the global setting!)
The remark in the manual (and online) that the variables have to be only defined is NOT true, unless set to "true" they do not have any discernible effect.
BTW: the ExtraDataItem line is:
<ExtraDataItem name="GUI/Dbg/Enabled" value="true"/>
I decided to set it up: this way all the VMs have the 'Debug' menu enabled but start as usual, if I want to debug one from the start then I use the command line with
-E VBOX_GUI_DBG_AUTO_SHOW=true
https://reactos.org/wiki/VirtualBox#Built-in_VirtualBox_.28low-level.29_debugger explains things a little better, however only for Windows (I presume 7 ...). There are 3 methods:
1 - Start VBox from the command line window adding the options as listed (see the VBox User manual for the command line method of running). The advantage that it is per machine, disadvantage: the command line is long and best issued from a shell script (in case of Windogs: BAT or CMD).
2 - Declare the environment variables:
I tried some under Windows 7 (64-bit Enterprise), here I declared User environment variables VBOX_GUI_DBG_ENABLED and VBOX_GUI_DBG_AUTO_SHOW (Computer / Properties / Advanced System Settings / Environment Variables) and after restarting Virtual Box GUI when I started the VM it would come to the debug console. My VM was x86_64 and like many other kernel debuggers this one was quite useless for stepping through ROM BIOS (at least the initial portion). I am too lazy to see if I can set the break-point either after the ROM BIOS is RAM-ed (relocated to RAM) or in the boot-loader (1st I would have to find if and how this VM relocates BIOS and then where would be the best place to break into the boot-loader, which is custom); but I did things like that in the past with similar debugger (this seems to borrow stuff from the oled Compusoft's CodeView x86 kernel debugger ..).
3' - Modify VBox global or per-machine configuration files, I have not tried that but I tracked the global file:
%homedisk%:\Users\%username%.VirtualBox\VirtualBox.xml
it is pretty straightforward, I assume adding the listed item shoudl work (%homedisk% is usually C, substitute %username% for the login name).
3'' - Modify the indiviual VM's file (*.vbx). They VM's are in %homedisk%:\Users\%username%\VirtualBox VMs
The *.vbox files are XML format and find where to add the data is also simple. This method has advantage of being perVM, disadvantage of possibility of screwing the VM up (so make a backup)
I have VirtualBox on my home iMac but I have not tried this yet. I did not dig into VirtualBox on Mac file structures, but I would be surprised if they were not somewhat analogous to Windows. The command line should be pretty similar (paths of course would be different, and the shell script too), one possible annoyance might be that you may have to use sudo ...
Regardless of the host, debugging the initial boot sequence of x86_64 is not trivial because usually in the beginning we time-travel to 80s and pretend that we are running 386 with two cascaded PICs and the extended address lines controller by a keyboard controller ... lots of fun! (or not ...)
I have a few VMs in Parallels 11, running several different versions of OS X, for automated software builds.
I recently copied those VMs to a different host, so I'd have a second set to fall back on in case of a hardware failure.
The problem: the copied VMs have the same Hardware UUIDs as the corresponding originals, and that causes a problem backing up the VMs with Time Machine, since Time Machine links backup images to machines by their Hardware UUIDs. If you have two VMs with the same Hardware UUID, Time Machine running in those two VMs will try to write to the same sparsebundle file on the backup server.
I googled the issue and found this: http://kb.parallels.com/en/11197 -- but those instructions don't work for Parallels 11: when you double-click the pvm, it is imported immediately, without asking whether it was moved or copied. When I first imported the copies, Parallels asked me whether the VMs were moved or copied, and I answered that they were copied. The KB article makes it sound like that should have made Parallels assign new Hardware UUIDs to the VMs, but that didn't happen (it did assign new MAC addresses, though).
I'm going to try finding the Hardware UUID in the PVM using a hex search; if I can find it, maybe I can change it manually, using a hex editor. It seems like a very yucky procedure, though, for something you'd think Parallels should handle itself. Is there any better way of doing this? Is this a bug in Parallels 11, or did they deliberately remove the Hardware UUID reset functionality (and if so, why)?
I was able to change it by:
Shutting down the virtual machine
Find the virtual machine bundle located on disk in Finder, right click on it and "Show package contents" on the actual .pvm file.
Then find the config.pvs file inside and open it with a text editor.
Change an arbitrary digit in the <SourceVmUuid>
value
Start the virtual machine
You can then go to:
About this Mac -> System Report -> Hardware
and inspect that the Hardware UUID has changed.
I've added some code to the Windows Filtering Platform MSNMNTR sample for my own application, but it still has the same structure. I've compiled the driver and the application for Win8 64-bit and production-signed the driver. On the (virtual) machine that I built the code on, the sample works fine and monitors correctly. When I copy the inf, sys and exe to another machine, the sample does NOT monitor. Through traceview output, I can see that on the second machine, DriverEntry() is not called, therefore the flow controls are never set up. The two machines are running the release version of Win8. It doesn't appear to be an issue with my new code, since the driver works fine on machine #1, and it doesn't appear to be a signature problem because when I turn off signature enforcement on machine #2 I still have the problem. Both the release and debug versions of the code have the same issue. The steps I use to set up and run the code are below. What are some things that might cause this behavior?
Copy driver .pdbs to a folder for traceview.
Right-click .inf and choose "Install"
Run "net start msnmntr" from an elevated command prompt.
Start traceview as administrator.
Run "monitor monitor "C:\Program Files\Internet Explorer\iexplore.exe"" from an elevated command prompt.
P.S. I haven't put windbg on this yet, but I will update the question with the results as soon as I try it.
Edited to add: OK, I ran the kernel-mode debugger on both machines and saw a difference in behavior. First of all, DriverEntry does get called on both machines. I was mistaken about that. However, on the machine where the code works (i.e. monitors web traffic) DriverEntry gets called when monitor.exe is run (step 5 above), and on the machine where the code does not work DriverEntry gets called when "net start msnmntr" (step 3 above) is executed.
The problem was that I had not installed the callouts via "monitor addcallouts" on the second machine. Since this is a one-time step, I had forgotten I did it weeks ago on the original machine.
I don't know where i make a mistake. I try to connect mi host pc (Windows 7) to target pc (virtual machine with Windows 7) in order to start with remote kernel debugging.
Vmware (virtual machine) serial port settings:
Windgb kernel debugging:
Boot virtual machine settings:
If I turn on or turn off virtual machine, nothing happens..
Does anyone know what I'm doing wrong? By the way, is it possible to view content of variables in a driver using LiveKd?
I changed debug port to 2 and host machine can connect to target machine, but windbg get error message "Assertion failed: Missing StreamContext Support ..." and VM hangs at the "Starting Windows" and nothing more happens..
Those settings look correct to me. Occasionally when I see the same behavior I just tell WinDbg to "Break" and that appears to finish the connection.
I've been struggling with much the same thing. It's been a while since I've spent much time kernel debugging with Windbg. I run Linux for pretty much everything, so this time I tried using two KVM/QEMU VM's managed by Libvirt. Lots of different complexity there, since the version of Libvirt I'm using doesn't provide easy "ui" methods of connecting serial ports between VMs (Libvirt hint: the XML setup for the serial ports, one system's Serial port source type must be set to "bind" and one system set to "connect", even for serial type "unix")
Finally, I was able to use Putty on both VM's and chat back and forth, confirming the COM ports I've chosen are indeed connected.
... and still Windbg on my debug host continued to say "Waiting to connect..."
Just confirming #jcopenha's answer, sending Break did just work for me (I don't have Break on my laptop kbd, so I used the Debug Menu to choose "Break").
The Target system is frozen (yes, after the target was fully booted, which was another question I couldn't remember the answer to), and !process gives me interesting info from the target system. I would Up-Vote their answer, but I am new to StackOverflow and don't have the reputation yet.
Thank you!
Does anyone know ways of partially or fully automating driver test installation?
I am new to driver development and am used to more of a test-driven approach in higher level languages, so moving to the kind of environment where I can't easily test as I go has been a step up for me. I am using Virtual PC for my test environment and currently have to reset it, open device manager, choose the device, click through a bunch of "Are you really sure you wouldn't rather install one of these system drivers" type dialogs, then finally reset the test environment while restarting WinDbg in the host machine just as the test environment is booting up... argh.
After repeating this process many, many times already, surely there has to be a be a better way of doing this? What tools/methods/tricks do commercial driver developers use to run up their driver in a test environment?
Note, this isn't about unit testing drivers, I haven't got to that stage yet or know if it is even possible. This is just about firing up a test environment with WinDbg attached to make sure that some small change I may have done is doing what I expect.
It seems to me that a virtualization software + a "mock objects" (layering) approach (as suggested by Aaron Digulla) + scripts (as suggested by Sergius) can simplify device driver development.
But if you use Visual Studio to develop user-level applications, you can use it for kernel device driver development too with VisualDDK (+ VirtualKD to debug over a named pipe, which is faster than over a virtual COM port), which addresses specifically the annoyances that you mention; from its home page:
... This project brings the simplicity and
convenience of Windows application
development to the driver development
world. No more manual creation of
build scripts, copying of driver
files, installing drivers from INFs,
switching between WinDbg and the
source editor or waiting for seconds
after each step due to the extra-slow
virtual COM port. Just create a driver
project using a convenient Driver
Wizard, select a virtual machine, and
enjoy debugging your driver directly
from Visual Studio. Want to test a
change? Just normally press Shift-F5,
modify your driver, rebuild it and
launch again. VisualDDK will unload
the old driver, install the new one
and load it automatically and quickly.
Bored with WinDbg loading symbol files
for minutes and looking up symbols for
seconds? Just let VisualDDK optimize
this for you using its own DIA-based
symbol engine. Using C++/STLPort in
your drivers? VisualDDK will natively
visualize all STL containers and
strings, as good as Visual Studio does
for user-mode applications. ...
You can write some shell scripts (using sc.exe and devcon.exe) to automate deployment tasks (no opening device manager, clicking on buttons, etc). And make snapshot of the system ready to debug (needn't wait for system boot).
Don't forget to check your driver with DriverVerifier!
Example of my own script :)
sc create FsFilter type= filesys binPath= c:\FSFilterDrv.sys
sc start FsFilter
pause
sc stop FsFilter
sc delete FsFilter
Follow the advice I gave here. Basically, test as little as possible with the real system.
In your case, I've got another tip: Virtual PC is using a virtual hard disk (that's probably a file on your real hard disk).
You don't need to install your driver, you can simply replace the new files in the virtual hard disk. This is often not possible in the running system but in a virtual system, you can open the virtual disk file and change it (since Windows isn't locking the files in it).
I'm not sure about Virtual PC but other emulators come with tools to work with virtual disk images. If VPC can't do it, check out VirtualBox.
It all depends a little on what kind of driver you are writing. But in many cases, writing an appropriate makefile (or something similar) that handles driver installation, start/stop, and launching of a test harness can already be good enough.
I also configure all of my test machines to automatically logon (AutoAdminLogon), map net drives, and launch an appropriate command prompt after startup. Running a specific test is then a matter of typing in a single command only.
One word concerning VirtualPC: VirtualPC is very handy for kernel mode development, but do not forget that it emulates a uniprocessor machine only -- so be sure to regularly test the code on a multiprocessor machine as well. That said, the VHD trick may seem handy, but it somewhat ties you to Virtual PC -- writing appropriate scripts that equally work on VirtualPC as on a real machine therefore seems a better approach to me.
Finally, consider it a shameless plug, but if you are looking for a unit testing framework for Windows kernel mode code, I have written one: cfix.
I think the DevCon utility (described in this OSR Online article) will help you. You should be able to setup batch files that do the job on one click.
It's free to sign up with osronline.com, and you'll probably have to sign up to get to that article. And if you are writing drivers, you WANT to sign up. These guys have been doing this for a long time, and there's a LOT of really good info on that web site.