Link to home
Start Free TrialLog in
Avatar of John500
John500Flag for United States of America

asked on

How to use Visual Studio to debug a VBS script ( error: Unable to attach to the crashing process. The process has been terminated.)

I'm trying to debug a VBS in Visual Studio 2005 and I've done this before.  For some reason my current attempts keep failing and I don't get it.

Ideally I will debug this script locally as I launch it from a remote machine for which I have access.  Example:

cscript \\ServerXyz\Projectn\MyVbsScript.vbs //x

This script has no parameters and it doesn't matter whether I run it locally or not - I get the same thing.  Also, I know there is nothing wrong with the script because it runs every day on various machines to do the job it does.  I want to debug it to understand what it does.

Please advise as to how I can debug this script.  I'm thinking I should be able to browse to the script, attach it and debug it!!

Thanks!
ASKER CERTIFIED SOLUTION
Avatar of gregcmcse
gregcmcse
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of John500

ASKER

Appreciate the input.  Can you test on your own machine any simple script using VS 2005?

The thing that is bugging me is that I've done this before just about three months ago.  It's not the script that's causing the problem, I'm sure it's the way I'm calling the script from the command prompt:

cscript \\ServerXyz\Projectn\MyVbsScript.vbs //x

What's the difference between wscript and cscript?  Maybe that's the way I was doing it ......
Avatar of John500

ASKER

What's happening is the script runs regardless and does the job it is supposed to do.  The problem is that although the cscript .... //x qualifier/syntax does launch the debugger dialoge, the debugger doesn't 'attach' .... but the script really never crashes.  See the screen shot below:
cscript-error.JPG
Avatar of John500

ASKER

I see the fundamental problem as being there is no existing 'project' for the debugger to work with.  Given this constraint the ' cscript ... //x ' syntax attempts to attach the process (vbs script) to the debugger as if it had an existing project.  This is what is failing.

Thus, I attempted to work around this problem by creating a VB Console project and I changed the extension of the module from VB to VBS.  After I did this I pasted all the code I'm trying to debug into the module.vbs file.

I then tried to build the project but I received the error message below.  Since I'm new to vbs I'm not sure exactly how I should modify the code to accomodate this error.  Is this a simple modification?

Thanks
vbs-project.JPG
I don't think that's going to fix the problem, but you can try it.

In your VBScript, after you declare any global variables, add a line that says "call Main" ("call" isn't necessary, but is good form).  Then surround the rest of the loose code in your script with:

Sub Main()

    ' all loose code here

End Sub ' Main

Avatar of John500

ASKER

When I try to build I get:

Error:  Sub Main was not found

The code looks like this:

Globals here .....

Call Main()

Sub Main()

          loose code here

End Sub 'Main

Any ideas why it wouldn't like this?

Thanks
Avatar of John500

ASKER

This was the ticket thanks!  From work the pictures wouldn't display for the procedure given in the blog.  Thus, I didn't even give it a try.  However from home I was able to see the pictures and was able to create the VBS project.

Thanks again!
Just in case someone else comes along and finds this question, there is another instance where this message occurs.  I have been debugging WSF/JS/VBS code for years without needing to create a project.  However, when I went to Windows 7 x64, I encountered this same error message when I tried to debug a script with the //X //D at the command line.

The problem is that VS2005 is still a 32-bit application and, by default, a command window in an x64 edition of Windows is the 64-bit version (C:\Windows\System32\cmd.exe).  To debug, you need to use the 32-bit version of the command-line (C:\Windows\SysWOW64\cmd.exe).  This works fine and I just created a short-cut in my programs to point to either of the two flavors of cmd.exe.
Avatar of John500

ASKER

Appreciate the heads-up !