Real-Time Measurement and Control

cancel
Showing results for 
Search instead for 
Did you mean: 

0xC0000005 exception

Highlighted
hi,
why I am getting an exception 0xC0000005 on real time pc, while running my VI program on Real-Time desktop, which uses Daq-Assistant for aquiring voltage signal.
previously it was running fine..!!
 
 
Altaf
0 Kudos
Message 1 of 7
(3,767 Views)
Highlighted
Hi Altaf,

The PharLap RTOS (which LabVIEW Real-Time runs on) is Win32 API compliant, meaning 0xC0000005 is the Windows error message for a memory access violation.

Can you post more information on this problem? Is it reproducible? Does it only happen with certain DAQ Assistant settings?

If the code is simple enough, can you post it to the forum so we can reproduce and investigate the problem internally?

Cheers.

| Michael K | Project Manager | LabVIEW R&D | National Instruments |

0 Kudos
Message 2 of 7
(3,755 Views)
Highlighted
Hi Proven Veteran, Altaf,

I seem to have exactly the same problem, I will outline my system:

PXI-1044 14 slot backplane & housing
PXI-8184 CPU with RT embedded software (no dual boot)
PXI-6225 etc. various M series DAQ cards (3 in total)
Dedicated Ethernet section to DHCP server and PC with LabView

System worked in the lab, we then deployed the PXI box to the place where it is to be used and now it is dead.
Investigating with a monitor on the VGA port, it starts OK, gets an IP address and says 'Welcome to LabView Real-Time 8.5'. It then starts a load monitor on the top line of the screen. All is well for maybe 5 seconds then a message comes up 'Rebooting due to exception 0xC0000005'.

It then re-boots and again gets an IP address. This is followed by 2 messages 'Reboot due to system error.' and 'Systems status: Safe Mode (Software Error). It stays like this until I cycle the power or press the reset button, it is sort-of seen in MAX but without any IO

Any ideas very welcome!

Cheers
Richard (MQ)
0 Kudos
Message 3 of 7
(3,567 Views)
Highlighted
Hello Richard,

Does the controller reboot every time?
Is there a startup executable running on the controller?
If so, does removing the DAQ VIs from the application alleviate the problem?

I would be interested in seeing a simplified example, if possible. If not, we may need to use your local Applications Engineering department to investigate the issue.

Cheers.

| Michael K | Project Manager | LabVIEW R&D | National Instruments |

0 Kudos
Message 4 of 7
(3,550 Views)
Highlighted
Hi Michael,
 
Richard is currently in contact with myself at NIUK Applications Engineering to troubleshoot the controller issues further, thanks for your response to the forum and when a solution is found it will be posted here for the community.
 
Kind Regards,
Applications Engineer
Message 5 of 7
(3,545 Views)
Highlighted

hi guys,

I solved this problem jsut re-installation of real-time module on the Real time target pc..!! and then it is working fine..it was might be due to some corrupt files..!

cheers..

altaf

0 Kudos
Message 6 of 7
(3,540 Views)
Highlighted
Yes, re-installation of the RT target was indeed the cure. It seems the flash disc had become corrupt, with help from UK support (Rob) I was eventually able to re-install it and all seems well.

Re-installation though had to start by upgrading the host PC to Labview 8.5.1 before doing the same to the RT target via the MAX application. Only to discover that the included DAQ-mx driver 8.7.1f2 has a bug that stops the PC from playing with the target (thanks again to Rob). So I had then to download and install DAQ-mx 8.7.1f3 on the PC, re-boot it yet again (no thanks to Bill G for such a lousy OS) before feeding the driver to the target. Finally it all seems OK!

Thanks again to all
Richard.
0 Kudos
Message 7 of 7
(3,518 Views)