Forum Replies Created
-
Posts
-
Was there an error message when you clicked “unmount”?
What happens when if you double-click at the drive icon in Explorer? Does the drive open, or is there an error?
Is the CDROM still visible in Device Manager?Stop. Did you perform the installation correctly?
1. Rename “normal” VBoxDD.dll to VBoxDD0.dll
2. Copy VirtualKD’s VBoxDD.dll to VirtualBox directory (in place of the original VBoxDD.dll).
Both steps are vital. VirtualKD’s version of VBoxDD.dll should be used by VirtualBox instead of the original. However, it will redirect normal requests to the original DLL (it expects it to be called VBoxDD0.dll).Please uninstall VirtualBox, remove all contents of OracleVirtualBox folder in Program Files, reinstall it and use the VBoxDD.dll from VirtualKD 2.5.4. It supports VirtualBox 4.1
Then you don’t have a network connection between the VM and the host machine. Try adding another network card in the VM settings and selecting “host-only” as the connection type.
That looks like a strange bug in VS2010. Do you have the latest service pack installed? If yes, please create a dump file using Visual Studio (Debug->Save dump as) and submit a link to it here.
As another workaround I can suggest getting msdia.dll from VS2008 and registering it in your system. VisualDDK will automatically use it instead.This helps partially. Please get symbols for both MSDIA100 and DDKDebugger-dbg:
1. Download http://visualddk.sysprogs.org/DDKDebuggerPDB.zip
2. In Visual Studio right-click on a line containing msdia100.dll, select Load Symbols -> From microsoft servers
3. Right-click on a line containing DDKDebugger-dbg, select Load Symbols -> From file, specify the PDB file from the archive
This should update the call stack and make it more informative. Please submit a new screenshot.Which BD player are you using? Could it be that the player keeps on running, accessing the drive letter and preventing the disc from being ejected (just like on a physical drive)?
The module is DDKDebugger-dbg.dll. Normally, you simply attach and press the OK button in the “please attach debugger” dialog. This will cause a forced breakpoint, so that the debugger will stop and show the error location.
Yes, but I’ve got very strange results. Visual Studio shows the wow64 functions in the call stack and pretty much nothing more. I am not sure I can extract any info from that file. Could you try to attach to the process in VIsual Studio (debug->attach), press “OK”, let Visual Studio stop on a breakpoint and:
1) Create a dump using Visual Studio (debug->create dump)
2) Look at the call stack and make a screenshot of it.You can alternatively download the VisualDDK sources from SourceForge and have a look which code line causes the exception.
