Desktop Execution Trace Toolkit not showing Executable EXE

[benatoc]

My software would freeze after running a long period of time; I suspected a memory leak somewhere so I was trying to trouble shoot the problem with the desktop execution trace toolkit.

The toolkit worked great, I was running both the software (source code, not EXE) and the toolkit on my development computer and I caught two reference leaks and an error message.

I built the EXE and configured it as the following post.

http://forums.ni.com/t5/LabVIEW/How-to-configure-Labview-executable-for-Desktop-execution-trace/td-p...

When I copied my EXE over to the target computer (which doesn’t have labview installed), I tried to start a new trace connection by selecting "remote application instances) from my development computer (which is running the toolkit).

I think I established a connection after entering the correct IP and port number (the reason I think the connection is correct because it didn't generate any errors). The problem is; I don't see my EXE listed under "Main Application Instance". If I do select the main application instance (and run the EXE), it doesn't generate any events while I run my EXE, nor do I see any VIs under "configure displayed Events).

My next approach was to run the EXE and the toolkit both on my development computer. Same problem, don't see my EXE listed under "Main application Instance". This leads me to think it's a configuration issue but not a connection problem.

My question is,

1. Would the two reference leak have caused the EXE to freeze after running for a long period of time in the first place?
2. Am I supposed to see my EXE listed under the "Main Application Instance"?

The current system I am using on my development computer:

Labview 2011 SP1 (32-bit)

Labview 2011 desktop execution trace toolkit

Windows 7 (64-bit)

The target computer which is running the EXE:

Windows 7 (64-bit)

No labview installed.

My .ini setup:

server.app.propertiesEnabled=True

server.ole.enabled=True

server.tcp.acl="A long string of numbers"

server.tcp.enabled=True

server.tcp.paranoid=True

server.tcp.port=3333

server.tcp.serviceName=""

server.vi.access="+*.*"

server.vi.callsEnabled=True

server.vi.propertiesEnabled=True

WebServer.TcpAccess="c+*"

WebServer.ViAccess="+*"

DebugServerEnabled=True

DebugServerWaitOnLaunch=False

[Sam_Sharp]

1) Yes, it's quite possible. Memory/reference leaks can cause undesirable behaviour including application crashes etc.

2) Yes, it's almost definitely a configuration issue. You should see <Your App Name>.exe listed in the drop-down box along with 'Main Application Instance' if you have your executable configured correctly.

Things I can think to check off the top of my head:

- Executable has debugging enabled

- VI Server port doesn't conflict with other applications/instances

- Windows firewall?

- Ensuring that the host can connect to VI Server (e.g. the "*" in the access list) - I think that's in the build specification as well?

- Ensuring the project VI Server is configured correctly for the project (right click 'My Computer' in the project and then properties)

- I think there's an INI key for enabling the debugging over TCP/VI Server (Yes there is - DebugServerEnabled=True)

[benatoc]

1) Enable debugging has been click.

2) I don't think its a port issue becuase the EXE doesn't even show up if I run both EXE and toolkit on the same computer.

3) Target computer is a stand alone system and the firewall is disabled.

4) I do have * in the access list, as well as 127.0.0.1. according to step 7.

http://zone.ni.com/reference/en-XX/help/372641A-01/lvdetthelp/debug_built_apps/

5) Did that too.

6) the .ini should have been setup correctly.

[benatoc · Accepted solution]

I finally got it working... it was a stupid mistake.

I should have selected "Application or shared library" instead of "Remote application instances" when I was trying to create a new trace.

Thanks for the help.