VMware Communities
Fred78
Contributor
Contributor

VMDebugger error: "unable to detect the current startup project"

Hi,

On my XP-SP2 host, VMDebugger is installed as an add-in in Visual Studio 2005 SP1. VMWare 6.0.2 is also running.

When I select VMWare\Start or Options in the Visual Studio menu I get the following error in a dialog box: "unable to detect the current startup project".

The project I wanted to run is properly selected as the startup project in the visual solution. The solution contains several projects and there are sub-folders.

In Visual Studio output window, I get the following text:

An error has occurred in the application. For more information please see the log file. Its path is listed in the About box.
An error has occurred in the application. For more information please see the log file. Its path is listed in the About box.
Error: Unable to detect the current startup project.

and the log file contains:

24/03/2008 18:35:22: ERROR: pProj->get_ProjectItems(&pProjectItems)
24/03/2008 18:35:22: An error occurred in .\Connect.cpp at line 1785.
24/03/2008 18:35:22: An error has occurred in the application. For more information please see the log file. Its path is listed in the About box.
24/03/2008 18:35:22: ERROR: FindProject(pEV, startupName, pProject)
24/03/2008 18:35:22: An error occurred in .\Connect.cpp at line 1792.
24/03/2008 18:35:22: An error has occurred in the application. For more information please see the log file. Its path is listed in the About box.
24/03/2008 18:35:26: Error: Unable to detect the current startup project.
24/03/2008 18:35:26: ERROR: DoConfig()
24/03/2008 18:35:26: An error occurred in .\Connect.cpp at line 438.

The "Attach to process..." action seems to work properly, as I get the list of process from the VM Machine currently running.

Any idea what could be wrong ?

Thanks,

Fred.

0 Kudos
7 Replies
KevinG
Immortal
Immortal

Hi Fred,

I assume you have the project open in Visual Studio before you try debugging.

How is your project directory structure ?

Have you tried WS 6.0.3?

If you create a simple new project, do you have the same issue?

0 Kudos
Fred78
Contributor
Contributor

Hi KevinG,

Thanks for your reply.

I've just tried with a simple solution containing only one project, and it works fine, the configuration dialog box opens properly.

The structure of my other solution is the following:

Solution 'XXX' (20 projects)

..|--SubFolder1

..|--SubFolder2

..|--SubFolder3

......|-Project3-1

......|-Project3-2 (the one to execute in the VM)

......|-Project3-3

..|--SubFolder4

..|--SubFolder5

I haven't tried yet the 6.0.0.3. I've looked quickly to the change log and there is nothing related to that. If you think I should try anyway, I will update to the 6.0.3.

Fred.

0 Kudos
grossag
VMware Employee
VMware Employee

Thanks for the post. I doubt this was fixed in 6.0.3 because we hadn't seen this problem. I have filed a bug internally and will let you know if we have any follow-up questions.

0 Kudos
kkaila
Contributor
Contributor

I have the same issue on my 64-bit XP Workstation using VMWare Workstation Beta 2 with a multiple project setup. I tried a single project solution and that seemed to work fine.

0 Kudos
buddylott
Contributor
Contributor

I am hitting this problem right now in Visual Studio 2008, VMWare Workstation 6.5.3 build-185404, and Vista Ultimate 64 bit.

I haven't see a solution posted. Is there one?

I too have multiple projects in one VS solution. The one I want to run is selected as the startup project,

Thanks,

0 Kudos
buddylott
Contributor
Contributor

I still see this iss with VS2008 on the latest VMWorkstation & Win7

0 Kudos
InvaderZim
Contributor
Contributor

... and I got it today using VMWARE Workstation 7.1.3 build-324285 with VS.2010 on a Windows 7 Ultimate, 64-bit  (Build 7600) 6.1.7600 host, trying to debug in a Win2008 R1 VM. 

The projects in my VS.2010 solution are nested under folders.  When I dragged my "active" C++ project out of the folder to the top level of the solution file, this problem went away.

VS has had folders for a long time, so I'm surprised this isn't fixed.  I'd file a bug report but I think VMWARE charges for that privilege...

0 Kudos