Forum Replies Created
-
Posts
-
This was originally done to make Device Manager display correct image names as device names. However, the overhead of “new device found” every time really seams unreasonable. It will be fixed in the next version.
Please try this fix: http://wincdemu.sysprogs.org/wcdcleanup.exe
Please inform me whether it solves your problem. If it does, I’ll fix the next version of WinCDEmuOk, does the COM-based or VM-based debugging work on your machine? Maybe, the problem global to VisualDDK and not related to 1394 directly? Additionally, maybe it is some kind of a problem with UAC? Does Visual Studio have the same access level, as WinDbg?
OK, is WinDbg closed when you are connecting from VisualDDK? Have you specified the path to the latest version of Debugging tools in VisualDDK settings? When you use WinDbg, did you specify “1934:channel=0” in command line, or did you use the dialog box?
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.
