I am facing a similar problem but my problem is with windbg.
I am running x86 win xp vmimage(target machine) on top of x64 win 7(host machine). I have modified the boot.ini of the target machine as following:
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)WINDOWS=”Microsoft Windows XP Professional” /noexecute=optin /fastdetect
multi(0)disk(0)rdisk(0)partition(1)WINDOWS=”Microsoft Windows XP Professional Debug” /noexecute=optin /fastdetect /debug /debugport=com1 /baudrate=115200
and using the following command line to run windbg and connect to target machine’s kernel:
cd C:WinDDK7600.16385.1Debuggers
windbg -b -k com:pipe,port=\.pipecom1,resets=0
I have also made the necessary changes to the serial port settings of the vm as shown in the following image:
[img]C:srlport.jpg[/img]
But despite doing all this I am unable to connect windbg of host machine to connect to the kernel of target machine. I always get the folowing output displayed on windbg:
Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Opened \.pipecom1
Waiting to reconnect…
This is troubling me since many days and i have reinstalled the winddk also to verify the installation. Any suggestion will be of great help.
Finally an answer after a lot of debugging and reading of google results!
It seems that there are two available formats for the .vsz file which describes the COM component to create in order to obtain an instance of the wizard.
First there is a plain text format and second there is an apparently undocumented (no schema available) XML format.
If the .vsz file loader has any problems loading the file as plain text it will attempt to load it as XML. When both fail you see the error we are seeing.
It seems that the plain text load is extremely fussy about its text and the file MUST be in ANSI PC format with no leading white space to be accepted.
In my case the problem appears to arise because the BzsDDKWiz.vsz file has become ANSI UNIX format and thus the plain text load fails as does the subsequent XML format load.
I guess the incorrect file format is an attribute of archive file extraction, I fixed it by loading the file into TextPad and saving in ANSI PC format.
I thought I had the same problem with VirtualBox 3.2.12 r68302 until I realised that I needed to use the latest version of VirtualKD (2.5.1) rather than the version that ships with VisualDDK.
2.5.1 introduced support for VirtualBox 3.2.x
By downloading the newer version (2.5.1) of VirtualKD and following the instructions in the readme.txt file I managed to patch virtuall box successfully on the host (by copying the new VBoxDD.dll) and install VirtualKD on the guest.
The apparent hang of the guest at startup in my case was simply that it was waiting for the kernel debugger to attach. Make sure you have windbg or kd running on the correct pipe before you let the guest boot.
I’ve now tried this on a virtual machine with only VS2008 pro installed. The same error occurs. I’ve rebuilt the ddkwiz project, registered the COM server by hand and I still see the same error.
I have debugged the devenv process that I’m attempting to use the wizard from and there is no evidence at all that the wizard assembly is being loaded. There are a couple of first chance excpetion 0xE0000001 being thrown but they are handled.
I can create an instance of ddkwiz.BzsDDKWizard from oleview.
Connecting through COM1 named pipe seems to deadlock both VS2008 and VMWare. Both are unresponsive, but they are not marked as ‘Not Responding’ by Windows so I think it’s a livelock, they are running but not progressing a bit.
Maybe this is due to VMWare 7? I see in “compatibility” only 6.5.x, not 7.x releases.
