Exe not responding for 5 minutes on exit

[ASTDan]

Hello,

I have a very strange error.

I have a LabVIEW 2017 built exe.  When my customer closes the exe on her machine the exe does not respond and won't close until we wait 5 minutes.

The exe closes as expected on my machine.

I have verified my LabVIEW exe program is done when this error happens.  I have run desktop execution trace toolkit and found no memory leaks or unclosed references.

Any ideas?

[aputman]

What's the error?  Can you share any code? 

It will be very difficult to propose a solution without fully understanding the problem. 

[ASTDan]

Hello,

There is no error code associated with this.  I go into task manager and it says the exe is not responding.  After 5 minutes the exe closes.  It should close right away.

I could share the exe... but you wouldn't have the hardware that it connects to.

Thanks

[aputman]

Sorry, I assumed there was an error code based on your original post. 

It sounds like a timeout value for something is set really high.  Or maybe your shutdown procedure is not executing in the proper order?  Is execution stuck inside a long running loop? 

Throwin' darts without a target here.  Gonna need more information (i.e. code).  The EXE will not be helpful. 

[billko]

Do you handle errors inside your code?  Do you have a trap for unhandled errors?  I always have a final trap for unexpected errors that do something like show the error and some kind of dialog.  There could be an error inside the exe that gets swallowed due to automatic error handling being turned off in an executable by default.  (No convenient pop-ups.)

(This has the advantage that the error becomes "known" and can be handled in the next release.)

[wiebe@CARYA]

I see this on some systems.

One is my own development system. Closing LabVIEW sometimes takes forever. Even when no code is running...

Do you use anything specific? .NET, ActiveX, dll's, DVRs, etc.?

[Ben]

---

wiebe@CARYA wrote:

I see this on some systems.

One is my own development system. Closing LabVIEW sometimes takes forever. Even when no code is running...

Do you use anything specific? .NET, ActiveX, dll's, DVRs, etc.?

---

I have seen that as well with LV 2017.

While I have not studied it to any extent it SEEMS that the longer LV has been up without being closed (in my case that could be weeks) the longer it takes to close. Additionally, if I watch the memory allocated to the LV process in Task manager >>> Processes tab, I will watch LV increase its memory usage for quite some time before it finally exists.

But I do not see how that could be the same situation in an exe.

I can only shoot in the dark as well.

Are;

DSC

DB's

or

dll's

involved?

Ben

[wiebe@CARYA]

---

@Ben wrote:

---

wiebe@CARYA wrote:

I see this on some systems.

One is my own development system. Closing LabVIEW sometimes takes forever. Even when no code is running...

Do you use anything specific? .NET, ActiveX, dll's, DVRs, etc.?

---

I have seen that as well with LV 2017.

While I have not studied it to any extent it SEEMS that the longer LV has been up without being closed (in my case that could be weeks) the longer it takes to close. Additionally, if I watch the memory allocated to the LV process in Task manager >>> Processes tab, I will watch LV increase its memory usage for quite some time before it finally exists.

But I do not see how that could be the same situation in an exe.

---

The plot thickens...

I have it in 2013. Exactly the same. The longer LabVIEW (not the code) runs, the longer it seems to take to close.

However... I think that these 2013 symptoms started when I installed 2017. And I did read somewhere about others having seen this: LV17 affecting other versions. Might as well happen with 2018... 

So maybe some peripheral software, updated by 17\18 is also affecting 13 and other versions? Maybe the error reporting or something? This could be shared by the dev.env and the RTE.

Not sure I see memory increase, sometimes it jumps from 800 MB to 30 MB while working (which I'm sure is not possible). So basically I don't really trust task manager in Windows 10 anymore. It does move around quite a bit while closing, and there is disk activity. But very little (<2%) CPU usage.

I do use .NET, some dlls and 1 DVR class (instantiated often). No noticeable leaks of course. No DSC.

@Ben: Do you hibernate the PC during one session. I do. Not sure if it effects the close time.

[Ben]

---

wiebe@CARYA

... 

@Ben: Do you hibernate the PC during one session. I do. Not sure if it effects the close time.

---

No, no hibernation. I lock the PC (windows 7) at night and log in the next day.

Ben

Edit:

This thread made me curious since it seemed like "ET was phoning home" when I saw the memory increasing as if a file was being written etc.

So I found in;

C:\Users\bar\Documents\LabVIEW Data\VIObjCache\17.0.0r0\bjFileDB.vidb

what looks to be a DB of the VIs I opened.

Ben

[ASTDan]

Hello,

I am dynamically calling vi's.  I have made sure those close down correctly.  No .NET.  I am using the NI Modbus Library  I have used this library several times with no .exe problems.

My customer is using Windows 7 I am using Windows 10.  Could that be a problem?

I verified all my code is stopped.  It seems like the LabVIEW runtime environment is taking longer to close after my application is stopped.  I do call the Quit LabVIEW function at the end of my program.  Could that be causing a problem?

I found a thread on LAVA about killing the task.  This seems like the nuclear option though.

https://lavag.org/topic/16737-application-task-kill-on-exit/