physical memory dump

[RavensFan]

Certainly look for anything happening in loops that perhaps shouldn't be.

Examples:

Opening a file reference in a loop repeatedly, but the file is not being closed inside the loop.

Creating a DAQ task inside the loop without clearing or closing out the task inside the loop.  This is one I saw that caused a blue screen because the DAQmx functions deal with .dll calls down deep in their hierarchy.

Similar things with queue references, notifiers, ....

Anything where there is an open, do, close relationship.  If things are being opened repeatedly without the matching close functions, each reference that gets created takes another small bite out of the memory.  Do it enough times, and you'll completely run out of memory and crash in some form or another.

[851624047]

Hi Ben,

  I do not have VI analyzer kit. I had run my Main VI without executing Multiplexer VI in parallel. So far (almost 20 h time) I did not find PC crash. I enabled VI profile memory while running this trial and attached the results for your view. Hope it could give some clue with this problem.

Thanks

Senthil

[Ben]

---

851624047 wrote:

Hi Ben,

  I do not have VI analyzer kit. I had run my Main VI without executing Multiplexer VI in parallel. So far (almost 20 h time) I did not find PC crash. I enabled VI profile memory while running this trial and attached the results for your view. Hope it could give some clue with this problem.

Thanks

Senthil

---

 

Don't you hate it when things start working as soon as we start looking!

At this point is is going to be a gut-call on your part. As soon as you feel that the app has run twice as long as you expected, you should stop and do a sanity check to make sure the problem is still present. In this pass you WANT it to fail. If you hook the mux back up and you get the crashes again... then REJOICE becuase we will have a clearly defined course of action.

Ben