LabVIEW built .net interop assembly debugging

[jason1]

I currently have a C# GUI that calls a LabVIEW 2012 built .NET 4.0 interop assembly.  This works as expected but I'm having memory leak issues somewhere in the LabVIEW code and need to debug.  I know I can attach to the process by going to LabVIEW and selecting Operate/Debug Application or shared Library.. option from the menu bar, which opens the top level VI, and then I can drill down through the block diagrams until i reach the suspect VI (It would be nice if there was a project like view that I could go straight to the VI I wanted which is ~15 layers deep).  I have been unsuccessful locating my memory leak by just looking at front panels and setting probes, what i would really like to use is the tools/profile/Performance and Memory tool or Desktop Trace Execution Toolkit to collect stats on the VIs in the .NET assembly.  I haven't been able to get either of these tools to attach to the assembly.  Is this possible, or can they only attach to LabVIEW executables or VIs running out of the LabVIEW environment?

I have "enable debugging" checked in the build settings and  "TCP/IP" selected in the project properties for VI Server.

[mikeporter]

What is the .net assembly doing? Is it calling any external code? How fast is it leaking?

Mike...

[jason1]

The .NET assembly is a fairly large program the contains hardware driver calls to ~15 instruments, database read/writes and test execution steps.  The leaking is not 100% repeatable, but once it starts it continues indefinetely until Windows runs out of memory.  This typically takes >3hours. 

My initial assumption is an array or queue is growing out of control but since there are so many VIs in this application it's difficult to view them all.

[mikeporter]

What database?

Mike...

[jason1]

SQL Express 2014

[mikeporter]

Can you run the body of the code in the developmemt environment? Do you see the leak there? Perhaps a better of segmenting things would be to have main application as a stand alone executable, and let the .net be just an interface that communicates with the executable via VI server.

Mike...

[jason1]

This is a good suggestion and something we can investigate, but in order to save time I was really just hoping to use the tools already available to us and/or the desktop trace execution toolkit that we have paid for.  Can you tell me if it's possible or not with our current architecture?

Thanks,

Jason

[mikeporter]

I don't know if the toolkits will work. Plus, it could be specific to running in the .net environment. I once had a memory leak where the problem (using SQLite) only occurred when the code was running as a .net assembly.

Mike...