Exact Meaning of Resetting VI Dialog - Specific Context

[Mr._Jim]

Hi all,

I've seen many discussion threads related to the "Resetting VI" dialog, and I've read at least one KB on it.

Some context:

I've been asked to help debug an application that someone else wrote.

• Standard LabVIEW, no LVOOP or Actor Framework
• We're running LabVIEW 2012, calling a rather esoteric and complex module of LabVIEW code from TestStand
• We sporadically get a MS Visual C++ Runtime Error dialog that says LabVIEW.exe has requested the Runtime to terminate it in an unusual way

I've seen the "Resetting VI" dialog in the past, but in this case it reads:

"Resetting VI: foo.vi.ACBRProxyCaller.[Hex]"  (It's not really foo.vi - but for simplicity's sake)

I'm trying to figure out where to focus my efforts in isolating the problem.

First question:

Does this mean that LabVEW is waiting for foo.vi (the caller) to reset, or does the message mean that LabVIEW is waiting for the VI called by the ACBR node?

Second question:

Is the "Resetting VI" dialog usually indicative of the exact problem area, or could something else in the code be causing the crash, and LabVIEW just happens to be executing foo.vi because it takes the most time to execute?

I realize I'm asking generic questions and not giving a lot of information. Part of the reason for that is that this is a large and complex application that is challenging for me to decipher as a newcomer, and another reason is the proprietary nature of the application.

Any advice or direction?

Cheers,

Jim

[JÞB]

"

• We're running LabVIEW 2012, calling a rather esoteric and complex module of LabVIEW code from TestStand

• ---

That's usually a bad idea!

Runtime Errors from C++ should be a bit clearer! but at least you know what is cause who to puke.  I'd definatly set the LabVIEW module to open front panel when called and don't close it when after.  That should let you use the heirarchy view to see what is tying up the proxy server.

DETT may help to! (I beleive Pro came with DETT in 2012) The current DETT allows for easy selection of which application instances you watch.  Then you'll easilly find which processes are unclosed.

[Mr._Jim]

>  "That's usually a bad idea!"

Yeah, I agree. Don't ask me how I know! It wasn't my idea. 

...and it's been a while since I've looked at 2012.

I haven't gotten out the DETT in a while. That might definitely be worth trying... and programatically opening the front panel is exactly what we've been doing all afternoon. That and asking lots of pointed questions.

Something about this code module is getting hung up, and I don't really see any way to narrow it down other than to start disabling sections of code.

Well, thank you for your two cents and empathy.

Jim

[JÞB]

DETT, I'll sa it again.

[Mr._Jim]

I will DETT today, if DETT is a verb. 

I just need to track down who has the installation discs around here.

[JÞB]

 Downloads are here

[nyc_(is_out_of_here)]

---

@JÞB wrote:

 Downloads are here

---

I clicked on that link and nothing shows up.

[JÞB]

Silly search-  It re-directed to "dest" so you need to click the "Search for DETT" Link just below the search box.