Forum Replies Created
-
Posts
-
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.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”.
