Forum Replies Created
-
Posts
-
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.If I remember correctly, a call to exit(), that is equivalent to KeBugCheck(). You need to patch STLPort to handle such cases correctly.
Yes, BazisLib fully supports writing kernel-mode drivers and even has several examples of compact and efficient object-oriented drivers.
The discussion about “only C” is caused by the fact that misuse of C features would cause one write more lines, but misuse of C++ features causes one source line generate much more binary code (e.g. use of implicit std::string constructor from a constant string, when not needed), that results performance drop not noticeable by developer directly. That’s why, rather than carefully design C++ programs and check the result in disassembler for some cases, many developers prefer using “old plain C”.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?
