Forum Replies Created
-
Posts
-
Do you have any cd burning software installed? Something that can interfere with CD drives?
As for the uninstall, I have fixed it in WinCDEmu 3.3-1. Just download the updated file and install it over the old one. Then the uninstall will work.
http://sourceforge.net/projects/wincdemu/files/wincdemu/3.3/WinCDEmu-3.3-1.exe/downloadNot yet. The explanation is on the main page. Basically, issuing code signing certificates to individuals rather than companies is not a “usual practice”, so it takes time to negotiate things.
Please close WinDbg before you start debugging with VisualDDK. You cannot debug the same kernel using 2 debuggers in parallel!
Obtaining a certificate takes time when you are not a company. Unfortunately, this process is quite buerocratic. My best hopes are for the mid-April.
Yes, boot your VM in debug mode and create a snapshot. Then, every time you need to debug anything, just revert to that snapshot et voila!
You can always change the DLL path by selecting Tools->VisualDDK Options in Visual Studio.
BTW, does the 1394:// prefix work correctly?No, but you can try redirecting the host-side named pipe to the other VM using the GuestRPC protocol (http://articles.sysprogs.org/kdvmware/guestrpc.html). (You’ll need to modify the sources)
No idea, but you can google for something like “windows 7 testsigning desktop icons disappeared”. It is not specific to WinCDEmu.
Check your system settings regarding unsigned drivers:
This article can be helpful: http://www.mydigitallife.info/2007/12/07/disable-unsigned-driver-installation-dialog-prompt-in-windows-xp/No, the mounted images are read-only. If you want a free tool to create ISO images from existing files, see mkisofs (http://en.wikipedia.org/wiki/Cdrtools).
Ok, this seems to be some kind of incompatibility. WinCDEmu 3.x uses a new ‘virtual SCSI’ model to create virtual drives. However, most advanced commands (that go beyond just reading some data) are replied with “not supported” status. I guess, this confuses many 3rd-party products (e.g. Roxio) and causes them to crash. That also explains why I cannot reproduce the bug on any of my machines.
I will look towards including a ‘debug mode’ in the next release of WinCDEmu that will collect precise records of all received requests, so I will be able to understand why the 3dr-party components get confused. You can also e-mail Roxio techsupport, as, if their driver actually causes blue screens, the bug is contained in it and WinCDEmu can just provide a workaround by responding to more non-essential requests…Understood. Your case is quite rare and WinCDEmu was not designed to handle such use. I guess, you need a more advanced imaging system then… Good luck in finding it 😉
Unfortunately, I don’t have much time to look into details right now. However, I don’t think that relying on undocumented _CxxThrowException(), that can be changed in future versions, is a good idea. Moreover, I don’t explicitly see whether your example is compatible with x64.
I would suggest redefining __THROW_BAD_ALLOC using SEH. As SEH is already supported by WDK, that should not be a problem. We won’t get a full equivalent of C++ exceptions, however, this particular problem (handle npagednew() for STL containers) will be solved smoothly.
