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