Forum Replies Created
-
Posts
-
I did not test it on Windows 2000, however, I suppose, that the problem is due to some of API functions not supported by Windows 2000. Could you please perform a simple test?:
1. Try forcibly loading VirtDiskBus driver (net start VirtDiskBus from command line).
2. If the driver loads successfully, skip the next step.
3. Download Dependency Walker from http://www.dependencywalker.com/%5D and open VirtDiskBus.sys with it. Observe, which functions are not provided by Windows 2000 kernel and post them here.
4. Repeat steps 1-3 for BazisVirtualCD driver.
As soon as you provide enough information to pinpoint the problem, I’ll be able to release an update (if it is not related to some key functionality not supported by Win2K).
P.S. Regarding the digital signatures and x64, I’ll soon release an update based on Authenticode technology, that will allow running WinCDEmu on such machines after importing SysProgs.org certificate and enabling “driver test mode” via bcdedit. See the http://wincdemu.sysprogs.org page in one-two weeks.Could you please test whether VisualDDK wizard handles DDK2600 correctly, if you create an empty ntstrsafe.lib file in LIB directory?
Before creating a project, VisualDDK wizard searches for several header and library files in the DDK directory to detect correct include & lib paths for the project. You can see the search sequence in detail in the ProjectSettingsForm.cs file.
Basically, the following files are searched: ntddk.h, ntdef.h, wdm.h, excpt.h, guiddef.h, ntoskrnl.lib, hal.lib, int64.lib, ntstrsafe.lib, exsup.lib, amd64ntoskrnl.lib, amd64hal.lib, amd64ntstrsafe.lib. Could you please specify the paths for the files mentioned above on your system, so I can see, why VisualDDK does not find them.
It is very strange, that the wizard fails after successfully locating ntddk.h. Maybe, filemon shows failed attempt of locating other files (ntdef.h/etc)?
Additionally, you can recompile the DDKProjectWizard.sln solution and run the DDKProjectWizard2005 project (select devenv.exe as running executable). After setting breakpoint on TryCreateLocationInfoObject() method, you can see why exactly header search fails. Note that CreateLocationInfoObjects() calls this method four times for four different OSes (WLH/WXP/WNET/W2K), so, it is normally for some of them to fail, as not every DDK contains all four of them.Signing drivers via Microsoft is quite an expensive affair. So, as soon, as the project is free, you are welcome to search Internet for different workarounds for unsigned driver installations.
No, it is based on a virtual bus driver, that accepts requests from mounter application. When you click on an image, the bus driver reports that a new device was inserted into it (as if you have inserted a USB stick into USB port) and Windows loads the BazisVirtualCD.sys driver that presents the newly found device as a CD/DVD-ROM device. You can see it from Device Manager if you select ‘display devices by connection’.
That could be nice, however, CUE+APE & etc formats require special decoding module, multi-track mode & etc. Basically, to add this single feature, the source code size would be increased 5 times, that is not the way of WinCDEmu.
I cannot say that this feature will never be added, however, unfortunately, it won’t happen in the nearest future.
P.S. You can use various other free software for APE/FLAC decoding, such as Winamp plugins.I guess that the problem is caused by WinDbg using MASM syntax parser by default, and VisualDDK using C++ parser (switching it every time would be very slow). You can try using @@masm(nt!…), however, in the future versions, I’ll add automatic redirection to Disassembly window when the ‘u’ command is typed.
Regarding the automatic command completion by ‘TAB’, is there any textfile, containing a list of all WinDbg commands? Parsing help files and rebuilding it could be quite inaccurate. If not, I’ll maybe add this support to next version, but provide only a sample command list file, encouraging users to update it.What does .symopt show in WinDbg and VisualDDK? If you set symbol options in VisualDDK equal to WinDbg ones, will the bug disappear? If you open Disassembly window in Visual Studio, and type IoCreateFile (should work even without nt! prefix there), does it locate the function correctly?
Well, it’s a Microsoft policy in Vista x64 to prevent loading of unsigned drivers. As signing drivers by Microsoft requires quite a budget, it is not an option for free software, like WinCDEmu. A partial workaround is decsribed here: http://www.elandigitalsystems.com/support/code39faq.php.
VMMON is not needed while using VisualDDK, as VisualDDK takes its role using functions from KDCLIENT.DLL.
You can start VisualDDK debugging session even before the target OS is booted. In that case, VisualDDK will connect to VM and will be waiting for the OS to load. Basically, an open VIsualDDK session is completely equivalent to an open WinDbg session, from KDVMWare’s point of view.
