Page 2 of 2

connecting/attaching to an external process when debugging

Posted: Thu Feb 21, 2013 7:05 pm
by Alexander Riedel
I am not sure what the OP was asking, but PrimalScript does not have a .NET or native code debugger, so you can't attach to a process or a COM object with it.

Usually someone who needs to debug any native code component has Visual Studio (and presumably the source code to the component) and uses VS' native debugger. So we would just be adding something that the target audience already has. As you suspected the extra effort is not really worth it.

connecting/attaching to an external process when debugging

Posted: Fri Feb 22, 2013 4:01 am
by samuelz
[Post removed by moderator]

connecting/attaching to an external process when debugging

Posted: Fri Feb 22, 2013 4:37 am
by jvierra

Your question is about "how" to use PromalScript to debug a process. This si not a vbscript question. It is not about how to write a vbscript or why a scritp does not work. The question is tool related. QQuestins like that need to be addressed to the Sapien support forums for the tools as we her at the 'ScripingAnswers' side of the forum do not attempt to answer product related questions because we are not part of Sapien or of customer support. Alex and Davidc are both Sapien employees and will usually field your questions in the support forums very quickly.

I appologize for assunming youy were more technical. WHen you mentioned Visual Studio I assumed you were a programmer and woiuld understand what "attach" to a process meant.

You are asking about something that is not available in Visual Studio except if you choose to allow the VS debugger to debug "into": external processes. The VS debugger can do this. No script debugger can do this. Scritp debugging is handled in the security of the script and cannot step into native code like Visual Studio can.

There is not scritping tool or debugger that can step into native code except those debuggers that can run in the kernel API and use the Debug API. Thjis is just an absolute limit of Windows. Scritps are not allowed to execute in the context of teh kernel and script debuggers (Microsoft supplies teh script debugger API too) cannot execute outside of the script engines sandbox for security reasons.

You have rephrased your question but it is really pretty much the same question:

"when I dubug VBS in PrimalScript, how I "attach" the debug process with the external application."

By external application I suspect you mean when you create an automation process like Excel, MSWord or InternetExplorer using CreateObject. The answer is that you can't. You cannot "attach" a non-kernel debugger to anything. "Attaching" is a function of the Debug API for compiled programs running native code. Scripts ae interpreted and are NOT compiled. The script engines and debuggers have no access to teh native debugger. They just share a similar name. It is similar to calling a glider an airplane but it still will not get you coast to coast. Only a more sophisticated airplane can do that.

As for Alex - I amsure he was not defending anyone. I believe he was a litle surprised that you felt it necessary to end on a bad not by placing help in quotes as if no one had tried to help you. Unfortunately your question ws not well enough understood. Yuo have to understand that it is not always possible to know what a non-technical user means with some technical terms like "attach". You seem to be asking how can I step into an external process to into native code. This has nothing to do with attaching in a scripting context because scrip debuggers are not kernel debuggers and cannot be made to touch native code. They just fire off each line and report what happened.

If you have used CreateObject in VB6 or VB.Net to fire up an eternal process then VS can activate the debugger for that process because you are already in a kernel debugger. VB and VB.Net are not scripting languages. VBA is not a scripting language. There is the differnce that I tried to point out to you initially.

I am sorry the answer doesn't help you. It is not us who are to blame but it is just how Windows works. You cannot change the design.

As Alex and I discussed above, it could be possible to include a kernel debugger into PrimalScript but it would be a waste of time because those who needed it would already have a kernel debugger. A person wrtiting a script would not find most of the information useful from an assembly language listin with arbitrary labels. Only the progrmmer writing the code would have the source. If yuo were a programmer I suspect this would have been obvious. To a non-programmer I guess it seems that scripts can be debugged and dispaly source so all programs should be able to display source. No. SOure code does not come with Windows or with compiled programs and scrip s cannot be compiled. They can only be encoded.

I hope the answer to your question is clearer now and sorry for any confusion.

Here is a discussion of teh debug API and the "attach" method. It may help you to undestand why this won't work with script.

Part 1:
Part 2:
Part 3:

connecting/attaching to an external process when debugging

Posted: Fri Feb 22, 2013 4:41 am
by jvierra
Her eis how to debug from WSH into JIT debugger of Visual Studio (old method but still works)

This is from Microsoft. It explains how the scritp debugger can jump into the VS debugger. (This uses Visual Interdev but works with all).

connecting/attaching to an external process when debugging

Posted: Fri Feb 22, 2013 4:59 am
by jvierra
Actually there is one other possibilioty here that can be caused by someone using the incorrect names and technical terms.

If I assume that you are asking about how to script against an already running process then we can give you an answer.

In scripting and in Visual Stiudio we do NOT use CreateProcess for this and it is NOT calkled "attaching". It is called "connecting" to a process and WSH has methods for doing this. ... s.84).aspx

This uses remoting as a demo but it can be used to connect to an already existing object.

We can also use GetObject to retrieve an instance. ... s.84).aspx

Is this possibly what you are trying to ask about?

WIth GetObject you can just specify the already open MSWord document and it will return a reference object that can be used. Events can aslo be wired up. This is very useful but requires a bit of sophistication to get working. Look for examples all over the Internet.