I'm remote-debugging a Windows kernel-mode driver using WinDbg. The driver has issues in the initialization routine, leading to a bugcheck/crash when installing the device driver. When I detach the debugger, the target PC reboots and runs again into the same bugcheck.
In order to test a new version of the driver, I therefore have to boot into safe mode, uninstall the device using device manager and reboot into normal mode.
Is there any way to simplify this workflow so that the device driver is automatically removed upon rebooting after a bugcheck?
Additional infos:
I'm using dpinst to install the driver on the target PC
use .Kdfiles to pull a replacement driver during boot
Documentation From MS
Write Up in Nt Insider From Osr Online
if you are using windows 10 then you can leverage the -m option to provide a partial name
and forego the dospath C:\ NtPath \.\xx , %SystemRoot%
confusions in the map file formats ,
or as described here
my Battery driver is working on 64 bit , but is not working on 32 bit. Platform is windows.
I am not able to come to any conclusion. What could be the possibilities?
If the driver is available for windows x64, normaly it must be available for x86 also. So you should search for the driver. Most of the drivers can be installed by windows update without installing manually a driver, so start search the update. Also i think you dont need a driver for the battery or is there a special reason for? The laptop battery drivers / softwares often only install a power plan which also can be configured manually if you dont want to use the microsoft standard plans. greats
I am new to windows driver development, so please bear with me if my question is being too stupid. Well, I am not sure why, as MSDN suggested and also the way I perceived, the host computer, e.g developing the driver, and the target computer, e.g debugging the driver, need to be two separate ones. why such separation? I did try to merge those two by deploying and debugging a driver on the host computer, in which I am developing a driver, and it seemed work with no objection from windows. Thanks.
PS. Source like this http://msdn.microsoft.com/en-us/library/windows/hardware/hh698272(v=vs.85).aspx got me think so.
Practically, when you are developing and testing a driver, in many situation you will get system crash (BSOD) and your system may not be bootable. In such situations your development + debugger environment is also gone/in-accessible.
Two separate machines are required for kernel debugging. You cannot debug self by obvious reasons (a debugger and a debuggee are in the same kernel and a deadlock appears). Of course, the target machine can be a virtual one.
When we develop a driver and test it the system will crash and a blue screen (called BSOD - blue screen of death)will show up. This is not the case like developing a User mode application and it crashed due to a memory error. Your driver will be running as a kernel mode application , If it crashes due to any illegal memory operation then the whole system is gone. It is not a simple issue to resolve , You need to log into safe mode and remove the driver from your system to recover it.
Due to this it is preferred to use a target machine mostly a VM on which the driver is installed and a host machine there we will be using a debugger to debug the driver.
I was so happy today that I have been finally able to install Windows Phone 8 SDK and try it a bit. I installed fresh new installation of Windows 8 Pro into my virtual machine (I am running if from Parallels) and then installed Windows Phone 8 SDK.
Everything went smooth, Visual Studio Express is installed and running, but when I created new project and tried to deploy it, VS fails with really weird message.
First of all, message box informing that "The Windows Phone Emulator wasn't able to create the virtual machine: Generic failure" appears. Really informing, really professional - generic error, that's really good. Then the information that deployment failed appears (thanks a lot for keeping me informed about that, I didn't noticed that it crashed completely). And then in the Error List, there is an information about "Invalid pointer" - even better. No clue at all about what failed or what's wrong.
Can anybody help me with that? There is nothing on the internet about this topic so far and I don't know where the problem is. I scanned the Windows events and logs, but there is nothing (probably I haven't been searching properly, so please guide me through that if you can).
Anybody can help?
The Windows Phone 8 emulator requires hardware Hyper-V support. In particular, it requires second-level address translation, hardware assisted virtualization, and hardware DEP support enabled and to not be ran in a hypervisor(no nesting). If you bought your machine within the past 4 years you should have no problem with these requirements. You can check out this article to see more information about that and how to find if your PC supports it.
Because of these hardware requirements, this means you can't run the phone emulator inside of most virtualization technologies... With one exception: I've been using VMWare 9 which appears to include an "unsupported" feature to allow Hyper-V to work though.. So your only choice for running the phone emulator is to either buy VMWare 9 (or 8 with more configuration) or upgrade a physical machine to Windows 8
The unsupported way VMWare allows you to run Hyper-V inside of a VM is that there is a manual option (hypervisor.cpuid.v0 = “FALSE”) which basically tells VMWare not to report to the virtual machine that it's running in a VM. Hyper-V checks if it's running in a VM and won't work if it is, so this gets Hyper-V to work past that check. I personally have tested this whole nested-VM thing with the Phone emulator(including before public release), and other than being quite slow, it does work pretty well with no immediate crashes or anything.
There is a workaround for VMWare Workstation 8 as well in an answer below. However, 9 is much easier to configure, so if you have it use this method.
I ran into the same issue and I fixed it by enabling Hypervisor applications in this virtual machine and adding the following line to the .vmx file:
hypervisor.cpuid.v0 = "FALSE"
This got the emulator working just fine. I found this answer here.
Hope this helps.
Actually, it works quite nicely with VMware Fusion 5.0.1
All I had to do is to add to the .vmx file of the virtual machine the following lines:
hypervisor.cpuid.v0 = “FALSE”
vhv.enable = "true"
Save and restart VMWARE (obviously the VM must be stopped before the changes are made)
I'm right now debugging a test app from VS2012 using the emaulator inside a VM in my Macbook
I'm a happy camper
:-)
I posted the same question on Parallels forum.
Reply:
The emulator is actually a virtual machine, so we are talking about a vm inside a vm, this requires support for nested Hyper-V, which afaik is planned but not implemented yet, also VMWare Fusion already supports this, if you are so desperate.
————-
See Parallels forum post: http://forum.parallels.com/showthread.php?p=646448#post646448
This works for me
Set RAM to 4g
Set at least 2 cores
add to vmx file.
vhv.enable = "TRUE"
hypervisor.cpuid.v0="FALSE"
Goot article
http://social.msdn.microsoft.com/Forums/en-US/wptools/thread/ed72010c-321c-4667-97b2-3ff1540e7f87/
You need SLAT compatible hardware to run Hyper-V, which is a requirement for using the emulator.
Can you clarify what kind of hardware you're attempting to run this on, and if you have enabled Virtualization in your BIOS settings?
The "Invalid pointer" error just means it cannot connect to the emulator (and/or device).
Just as an addition to https://stackoverflow.com/a/13163762/1964969 (top answer at the moment):
manually appending "hypervisor.cpuid.v0" key works for VmWare Player 5 as well (the main reason - this software is free for non-commercial use so it's perfect product if you test the waters, just download from VmWare website and install, it's fully-functional).
Slightly unexpected, any of the following amends solve the problem with WP8 emulator:
hypervisor.cpuid.v0="FALSE"
hypervisor.cpuid.v0="TRUE"
hypervisor.cpuid.v0=""
Yeah, you can apply empty value for that key - but why? Have no idea but it works. I did some notes in my blog as well:
http://windowsasusual.blogspot.ru/2013/01/how-to-launch-windows-phone-8-emulator.html
Under Parallels Desktop 8 follow this guide: http://kb.parallels.com/en/115211
Edit:
Oh, I didn't noticed that you are trying to run emulator on VM. My answer is for non-VM environment.
First of all, you need to check hardware requirement at here
Be careful, successful installation of SDK does not guarantee "your hardware is compatible"
If your hardware is compatible and Hyper-V is running(described in the link above), please check your BIOS and be sure to enable hardware virtualization in CPU Configuration
(for me, I could find it at Booting > BIOS > Advanced > Advanced > CPU Configuration)
Brief summary:
64bit CPU and OS
4GB RAM
Hardware-assisted virtualization supported CPU
Second Level Address Translation (SLAT) supported hardware
Hardware-based Data Execution Prevention (DEP) supported hardware
Proper BIOS settings
For me the solution adding line:
hypervisor.cpuid.v0 = "FALSE"
I use VMware Player and added the line (hypervisor.cpuid.v0 = "FALSE")in the .vmx file.
My virtual machine with Windows 8 Pro runs the emulator for Windows Phone 8 perfectly.
Solved the problem by uninstalling an older VPN client from the machine. It turns out some VPN clients might have compatibility issues with Windows 8. After uninstalling VPN client I was able to run the emulator without issues (of course after making sure Hyper-V was installed and enabled on the machine)
Not enough rep. to comment on the accepted answer, but Microsoft provide instructions specifically for Fusion here. It worked for me, after a couple of reboots of both Mac and VM. I installed W8.1 without Hyper-V support initially and had to install it after the fact ("Turn Windows Features On or Off" in Control Panel), but apart from that no problems. Quite speedy on a 16Gb 2013 MBP.
I am developing a driver based on ddk sample "passthru" and I have trouble loading this driver in win7(x86 or x64). I have tested my driver in winxp (x86 and x64), and it works pretty well, but when I tried to load this driver into win7 (F8->Disable Driver Signature Enforcement), it seemed failed. Then, I tried the native passthru code, it also failed. I thought it failed because
I can not see any outputs using KdPrint fron windbg.
I can not see any useful information from system event.
I set a breakpoint on passthru!DriverEntry, it seems that DriverEntry has not been called.
My WDK is 7600.16385.1, and passthru is supposed to be compatible with win7. I compile passthru using command "build -cZ".
Could you help me understanding this problem, or any clue about why passthru not loaded in win7?
I have built this driver in win7 x86 checked build environment， and tested in win7 x86.
Solved: Actually, the driver has been loaded, but the output of KdPrint not shown in win7 by default, you should use KdPrintEx to specify message level, or modify registry to make debug message shown. Now I have no idea why bp failed either.
Normally you can't use a driver that was built for WinXP target on a Win7 machine. Rebuild for Win7 target.
Well your question is rather unspecific, but I see one particular problem here: Enabling test-signing and disabling kernel mode signing policy still requires you to sign the binary ... (after WHQL-tests MS would cross-sign the .cat file for the driver). Refer to this.
See:
For 64-bit versions of Windows Vista and later versions of Windows,
the kernel-mode code signing policy requires that all kernel-mode code
have a digital signature.
and:
The operating system loader and the kernel load drivers that are
signed by any certificate. The certificate validation is not required
to chain up to a trusted root certification authority. However, each
driver image file must have a digital signature.
These commands should allow to load a driver signed with anything
bcdedit.exe -set loadoptions DDISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON
You don't mention what target OS you chose when building. Icepack mentioned it. You need to actually build for Windows 7 to make it work with the new NDIS 6.0. Simply loading a driver built for XP (and older NDIS version) may not work at all.
My suggestion, use DDKBUILD.CMD and build one driver with (free build, W7):
ddkbuild.cmd -W7 fre . -cZ
and one with (free build, WXP)
ddkbuild.cmd -W7XP fre . -cZ
the above command line already takes into account the WDK you have. Note that if DDKBUILD.CMD fails to detect your installed WDK you'll have to set the environment variable W7BASE to point to the folder in which the WDK is installed (the one with install.htm, usually something like C:\WINDDK\7600.16385.1).