LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

physical memory dump

Hi,

   I am using Labview 8.2. I am using Field point (FP-2000) for DAQ via Ethernet cable to PC. Also I have also a serial data interface to PC from a multiplexer. I have two while loops in my main labview window and have sub-VIs running inside. Sometimes I observe crashing of PC and blue screen appears with following error:


  A problem has been detected and windows has been shutting down to prevent
damage to your computer.

IRQL_NOT_LESS_OR_EQUAL

Technical Information:
  ****STOP:0x000000A(0x0000BA34, 0x000000002, 0x00000001, 0x806E6A8E)

physical mmeory dump complete.

Contact your local administrator or technical support group for further support.

 

I am using Windows XP (2002 version). Current status of Hard disk is 12.8GB (used space) and 232 GB (free space). I also run a task manger while running all VIs and found a maximum of 20 % CPU usage.

 

Kindly anyone suggest me a solution for this problem.

 

Thanks

 

Senthil

0 Kudos
Message 1 of 23
(3,996 Views)

Watch task manager while the VI runs, and observe if the memory creeps up over time, to see if you have a memory leak.

 

Richard






Message 2 of 23
(3,983 Views)

851624047 wrote:

Hi,

   I am using Labview 8.2. I am using Field point (FP-2000) for DAQ via Ethernet cable to PC. Also I have also a serial data interface to PC from a multiplexer. I have two while loops in my main labview window and have sub-VIs running inside. Sometimes I observe crashing of PC and blue screen appears with following error:


  A problem has been detected and windows has been shutting down to prevent
damage to your computer.

IRQL_NOT_LESS_OR_EQUAL

Technical Information:
  ****STOP:0x000000A(0x0000BA34, 0x000000002, 0x00000001, 0x806E6A8E)

physical mmeory dump complete.

Contact your local administrator or technical support group for further support.

 

I am using Windows XP (2002 version). Current status of Hard disk is 12.8GB (used space) and 232 GB (free space). I also run a task manger while running all VIs and found a maximum of 20 % CPU usage.

 

Kindly anyone suggest me a solution for this problem.

 

Thanks

 

Senthil


Make sure your code is watching the serial port and keeping up with the incoming data. I have seen noisy multiplexers swamp a serail port and depending on the driver take a machine down.

 

As a first quick test, try disconnecting the serial and see if the crashes continue without the serial port.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 23
(3,980 Views)

Hi Senthil,

 

I have been looking into your problem for you. Firstly, the error message you are receiving certainly suggests a memory issue. 'IRQL_NOT_LESS_OR_EQUAL' indicates that a process or driver attempted to access a memory address to which it did not have permission to access. The 'Physical memory dump' message is usually displayed as a result of insufficient RAM. 

 

A memory leak in your VI is a potential cause of this problem which means that for some reason your computer is not able to release memory that it has acquired. It inevitably reaches a point where there is no memory left which could cause this error. I have found a link which may be useful in diagnosing and troubleshooting memory leak issues.

 

Having not seen your code, I can only speculate as to what may be the cause of your memory issues however, you mentioned you have two While Loops with sub VIs running inside. This can be the source of significant overhead and is not recommended practice, which may be contributing your memory problems.

 

I hope this helps you,

 

Christian Hartshorne

Applications Engineering

0 Kudos
Message 4 of 23
(3,938 Views)

CJHartshorne wrote:

Hi Senthil,

 

...

, you mentioned you have two While Loops with sub VIs running inside. This can be the source of significant overhead and is not recommended practice, which may be contributing your memory problems.

 

I hope this helps you,

 

Christian Hartshorne

Applications Engineering


Smiley Surprised

 

Hi Christian,

 

I would like to invite you to clarify that statement before anyone reads it and reads it as gospel (after all it was posted by a Blue bar "so it must be true" [See "Billy the Mountain" regarding Sudabaker Hawk, by Frank Zappa and the Mothers of Invention]).

 

Just trying to stomp false rumurs before they spread,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 5 of 23
(3,936 Views)

Ben wrote:

CJHartshorne wrote:

Hi Senthil,

 

...

, you mentioned you have two While Loops with sub VIs running inside. This can be the source of significant overhead and is not recommended practice, which may be contributing your memory problems.

 

I hope this helps you,

 

Christian Hartshorne

Applications Engineering


Smiley Surprised

 

Hi Christian,

 

I would like to invite you to clarify that statement before anyone reads it and reads it as gospel (after all it was posted by a Blue bar "so it must be true" [See "Billy the Mountain" regarding Sudabaker Hawk, by Frank Zappa and the Mothers of Invention]).

 

Just trying to stomp false rumurs before they spread,

 

Ben


 

Just to clarify, each sub VI call involves a small amount of overhead (computer processing resources, such as time and/or memory). As a result, subVI overhead can be significant if you place it inside a looping structure. These problems can be avoided by placing the looping structure inside the subVI, if possible. These problems are more prevalent in Real Time (RT) systems but can affect system performance on non RT systems. [Ref: LabVIEW RT Course Manual Version 8.6 - Page 3-22]

 

0 Kudos
Message 6 of 23
(3,920 Views)

CJHartshorne wrote:

Ben wrote:

CJHartshorne wrote:

Hi Senthil,

 

...

, you mentioned you have two While Loops with sub VIs running inside. This can be the source of significant overhead and is not recommended practice, which may be contributing your memory problems.

 

I hope this helps you,

 

Christian Hartshorne

Applications Engineering


Smiley Surprised

 

Hi Christian,

 

I would like to invite you to clarify that statement before anyone reads it and reads it as gospel (after all it was posted by a Blue bar "so it must be true" [See "Billy the Mountain" regarding Sudabaker Hawk, by Frank Zappa and the Mothers of Invention]).

 

Just trying to stomp false rumurs before they spread,

 

Ben


 

Just to clarify, each sub VI call involves a small amount of overhead (computer processing resources, such as time and/or memory). As a result, subVI overhead can be significant if you place it inside a looping structure. These problems can be avoided by placing the looping structure inside the subVI, if possible. These problems are more prevalent in Real Time (RT) systems but can affect system performance on non RT systems. [Ref: LabVIEW RT Course Manual Version 8.6 - Page 3-22]

 


 

 

 

Sorry but more smoke will not get rid of me rather it only get the adrenaline pumping.

 

Are you implying that evey iteration allocates more memory?

 

Feeling like I am being fed a line of Bovine Skat,

 

Ben

 

 

Message Edited by Ben on 11-17-2009 09:14 AM
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 7 of 23
(3,914 Views)

To back-up my assertion that a sub-VI in a loop does not nessesarily allocat emore memory durring each iteration, I offer this thread where Greg McKaskle explains when and why additional memory may be allocated when a sub-VI is called. As the exmaples posted in that thread illustrate, LV is very smart when it comes to allocating buffers and re-using them.

 

So a sub-VI in a loop is NOT a bad construct.

 

Ben

 

PS: I have benchmarked the overhead in calling a sub-VI and the over-head amounted to about 8 ps and can vary depending on the number of connectors on the icon. If your code has to worry about 8 ps then it is appropriate to think about not using a sub-VI.

 

PPS: The above cited thread is manditory reading for every developer I work with.

Message Edited by Ben on 11-17-2009 09:45 AM
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 8 of 23
(3,903 Views)

An IRQL_NOT_LESS_OR_EQUAL error is usually due to a driver attempting to access protected memory. The physical memory dump is just a record of the state of parts of the memory, eg the program stack, when the error occured

 

I would expect to see another line on the error message similar to       *** Address x has base at y - filename

Filename indicates which file, usually a dll, is involved with the memory fault. The fault could however be caused by another dll called by this one. 

  

Here's a link to a Microsoft knowledge base article on troubleshooting this type of fault.

 

Good luck!

 

Message 9 of 23
(3,886 Views)

Hi Ben and Christian Hatshorne,

  Thanks for your valuable comments. I attached herewith snapshot of my Main VI and hope it could help to track the problem. My Main VI has two while loops

1.DAQ loop (To acquire data from Fieldpoint and also data directly via serial interface at COM1 of my PC)

 

2. Update Loop (Here all acquired varaibles are processed in Sub-VIs and updated regularly).

 

Moreover in 'Update loop' I am also using acquired values from a multiplexer interface. There is seperate VI for multiplexer and is executed in parallel to my main VI. Datas were called in to 'Update loop' of 'Main Vi' via 'global variable'.

 

Thanks

 

Senthil

0 Kudos
Message 10 of 23
(3,874 Views)