Forum Replies Created
-
Posts
-
Installing WinCDEmu has enabled the “testsigning” mode (http://msdn.microsoft.com/en-us/library/dd419910.aspx). Without this mode, Windows 7 cannot load unsigned drivers (signing is not free). You can read more about testsigning (including how to disable it) here: http://www.sysprogs.org/signing/
Please try debugging using WinDbg+VirtualKD (start VMMON.EXE or VMMON64.EXE, select your VM, select the correct OS instance, press “Run Debugger” from VMMON).
If the WinDbg debugging fails as well, double-check your VM settings and VirtualKD installation.
If WinDbg debugging works, but VisualDDK still fails, ensure that the correct VM name is specified and that you are not running WinDbg while connecting from VisualDDK.
Anyway, feel free to post here after you try WinDbg.Ok, please gather all .dmp files from your WindowsMinidump directory, pack them into a ZIP file and send to support (at) sysprogs.org. This will help me to determine the reason of the problem and to fix it.
Ok, did you run the VMINSTALL.EXE on the VM? Did you select the “Windows [VirtualKD]” as the operating system to boot on the VM?
Please try raw:// prefix, as described here:
viewtopic.php?f=4&t=378In the current version you need to create a new project for that (if you are using the BUILD system, you can change the command lines in project settings). In the future versions it will be possible to select multiple target OSes when creating the project.
Could you please try “Debug->Attach” method, as described in VisualDDK quickstart? (http://visualddk.sysprogs.org/quickstart).
If “1394://” fails, try using “raw://” prefix, as described in the page above.
If using “raw://” solves the problem, please post your complete connection string here, so I can fix the “1394://” implementation.This problem is not related to network communication (pinging & etc).
Did you install the VBoxDD.DLL file from VisualDDK according to installation instructions (http://virtualkd.sysprogs.org/#installation)?Ok. There is a bug in Project Wizard that does not flag x64 configurations as x64. On my machine it results in building x86 binaries even if x64 was selected. To fix this after the project file was generated, please go to “Project Properties -> NMake -> Build Command Line” and insert “AMD64” before “Win7”. This should fix the problem.
Could you please send the contents of your “WindowsMinidump” folder, so I can investigate the “power failure” bug?
If ISO files do not open automatically, you can use the manual override:
1. Click on an ISO file.
2. Right-click and select “Open With->Select Default”
3. Press “Browse”
4. Select “Program Files (x86)WinCDEmuvmnt.exe” (or just Program Files… on 32-bit machine).
5. Press OK and try again.Ok, please try creating a BAT file containing the following 3 lines:
call C:WINDDK7600.16385.0binsetenv.bat C:WINDDK7600.16385.0 chk win7
cd /d c:UsersAdminDesktopDriverslegacyDrvlegacyDrv
buildLaunch the BAT file from Explorer. If that build succeeds, try launching the BAT file from “Visual Studio Command Prompt”. Maybe, there are some environment variable conflicts. If the BAT file fails, try to understand the difference with invoking “build” on its own (maybe, “cd” does not work?)
Please examine the entire output log (from the output window in VS) to understand why x64 build fails. You can also post the log here.
Regarding Virtual PC, you can use it, but the debugging will be extremely slow, as VirtualKD does not support Virtual PC. You can use either VMWare or VirtualBox instead.
