From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
02-06-2014 07:06 PM
Hi all,
I have kind of a mysterious error that I'm trying to get to the bottom of, and I was wondering if anyone has ever seen this before.
Quick background (more details can be filled in if needed):
I wrote a set of VIs which control NI hardware in a PXI chassis, and built those VIs into a DLL. Function calls into that DLL are made by various external applications written in C++ and C#. Unfortunately I am fuzzy at best with C++ and C#, so any questions about that aspect of it need to be very specific so I can ask people who are wiser in those languages than I.
Apparently, there is an application which links to the DLL I built, but never actually calls it. As I understand the situation, the reason they link to my DLL is that they MIGHT call it, if they're running on a machine that is connected to the PXI chassis.
If that application is running on a machine which has the PXI chassis connected to it (that is, the hardware is present), the error never occurs.
If that application is running on a machine which does not have physical hardware present, the error occurs intermittently. (nothing like the intermittent error) The machine in question has the appropriate version of RTE (2012, if it matters). Because I do not have access to the machines which exhibit this behavior, I have been unable to check the hardware driver configuration on those machines, and I'm not getting any information from the folks who do have access to them (I've asked repeatedly).
Has anyone ever seen the NI Error Reporting Server stop working? This is a new one on me and I'd be grateful for any insight that anyone can offer.
Thanks all!
Diane
02-10-2014 05:40 PM
Hey Diane,
Is it possible for you to give a bit more information about the error you are coming across? The error number or maybe a screenshot would be helpful. It would also be good to know which specific hardware drivers are being called in your VIs.
Finally, I'm not too sure what you mean when you say "the error occurs intermittently (nothing like the intermittent error)." Which intermittent error are you referring to?
If you can provide us with this information we'll be a bit better equipped to help you out.
Thank you,
Myriam D.
Applications Engineer
National Instruments
02-10-2014 07:00 PM
Hi Myriam,
When I say "the error occurs intermittently", I am referring to NI Error Reporting server crashing. I have attached a screenshot which results from the crash. I tried to attach the .dmp file also, but it was rejected.
The DLL calls DAQmx, RFSG, RFSA, and NI-DCPOWER.
I don't feel that you understand my setup very well. I have created a DLL using LabVIEW. This LabVIEW-created DLL is linked by another application, but never actually called. Therefore none of the functions in the LabVIEW-created DLL are running when NI Error Reporting Server crashes, because no calls are made to it.
It is only linked. The linking application does not call any of the LabVIEW-created DLL functions. Therefore, no LabVIEW code ever executes. And yet NI Error Reporting Server still crashes intermittently.
I assume that the NI Error Server is running because the LabVIEW-created DLL has been linked. Otherwise, I see no reason for it to be running at all.
Does any of this help clarify? It's a weird one, for sure.
Thanks for the response!
Diane
02-11-2014 04:44 PM
Hey Diane,
Thank you for the reply!
Could you tell me which version of LabVIEW you created the DLL with?
Something you could try is to make a very simplified version of your DLL file (not involving any hardware) and see if you can replicate the error you're getting by linking to it from another application. You can make the calling application event-based to let the user select whether or not to actually call the DLL file. If you can successfully replicate the error this way, it will help narrow down where it's coming from. Feel free to post the VIs.
Another (but less favorable) option you could try would be to disable NI Error Reporting using the steps outlined in this document:
http://digital.ni.com/public.nsf/allkb/368F508D3FAE0242862578D400770616
Let us know what you come up with.
Thanks,
Myriam D.
Applications Engineer
National Instruments
03-05-2014 09:56 AM
Hi Myriam,
We never did find the root cause of this. One of the C++ developers made what should have been an unrelated change to the caller and, as far as I know, we haven't seen the behavior since.
Go figure.
If the problem magically reappears, I'll pursue it further.
Thanks for your help!
Diane
11-18-2016 03:50 AM
Dear Diane,
I have also crash of NIER on a MS server 2012 R2. I'm running LV2015 on it.
Error report from windows :
11-21-2016 03:18 PM
Hi daniel_rudaz,
Are you using the 64-bit or 32-bit version of LabVIEW? Also, is your MS server 64-bit?
Regards,
Ryan
11-22-2016 03:01 AM
Dear Ryan,
I'm using Labview 2015 in 32 bits. The server is 64 bits.
There were two NIER servers running, one for 32 bits apps and one for 64 bits apps.
I have disabled the servers from Start and now my application is crashing.
Thanks for your help.
Daniel
11-23-2016 12:41 PM
Hi Daniel,
Could you please start a new thread? While this may be a NIER crash, unless you have a related DLL that may be causing the crash or a reason that it is directly related to the same issue, you should be openening a new thread rather than ressurecting an old post.
Thanks,
Patrick B
12-01-2016 07:30 AM