Unhandled exception (Access violation 0xC0000005) in CVIRTE.DLL upon exit

[Deshmukh]

I have PXI driver dlls created using LabWindows CVI v 7.1. If I link these DLLs in specific order in any ('C') application, I get error "Unhandled exception in XXX.exe (CVIRTE.DLL): 0xC0000005: Access Violation" when I exit the program. Note that:

• Error is generated only if these driver dlls (created using LabWindows CVI 7.1) are linked in specific order in Microsoft Visual C++ project. It is possible to avoid this error by changing the link order of the drivers in the project.
• No function from the dlls need to be called (except DllMain called by Windows) to generate this error upon exit
• Error happens after exit from the main program and no other functions in the call stack apart from CVI

Call Stack at the time of the error as below:

CVIRTE! 685c42d1()
NTDLL! 77f8806c()
NTDLL! 77f8a980()
KERNEL32! 7c596a0f()
doexit(int 0, int 0, int 0) line 392
exit(int 0) line 279 + 13 bytes
mainCRTStartup() line 212
KERNEL32! 7c598989()

Attached sample project (few lines of code with just printf) should be able to reproduce it (note that I have just added .lib files to the project and not the .dlls to reduce attachment size since it is not necessary to call any of the functions in the driver dlls to generate the errors.)

[Deshmukh]

Updated project with the DLLs (required to start the app) attached with this message.

Please ignore previous project attachment. Apologies for earlier incorrect project attachment.

[Deshmukh]

I removed the code from DllMain() of my Dlls to isolate the problem, so effectively no code in my dll (apart from return TRUE in DllMain()) is being executed but still it generates access violation in the CVIRTE.DLL, it means either the problem is in the CVIRTE.DLL or the instrument driver DLL generated by the CVI. I have attached new project with my modified Dlls (removed code from DllMain()). Can somebody at NI have a look at it ? (because only they can run the CVIRTE.DLL in debug mode and see where is this access violation)

Note that by changing the link order (of the user libraries) in the project settings make this problem disappear.

Thanks in advance

[bilalD]

Hello Deshmukh

Thanks for narrowing down the problem like this.

Is it possible for you to attach the source of the DLLs being loaded? I noticed that af3020 and 3010_32 are linked against instrusup and 3030 is using the whole cvirte. And they all seem to be dependant on some other afXXX DLLs. I'm trying to narrow down how we're ending up in the bad state in the first place.

If you are not comfortable with posting them on the forums, let me know and we can arrange an alternative mechanism.

Thanks

[Deshmukh]

Hi Bilal,

Thanks for your reply. Please note that instrument driver dlls (3010_32.dll, 3020_32.dll and 3030_32.dll) are generated by the LabWindows/CVI (which I think inserts DllMain() and also creates the dependency upon other dlls including standard windows and NI dlls such as instrusup.dll). They just contain the instrument driver functions and if you see the souce code of the example program, you will realize that none of the function from any of these libraries is called by the test program. All this test program does is to load the dlls (which calls the DllMain() of the libraries) and exit. I have removed the code inside DllMain() of my other dlls so effectively no other code from the my libraries (apart from DllMain() inserted by CVI) is executed after loading the dlls (and thats all the test program does).

We cann't give you the source code, but even if we gave it, I don't think it will help since no function is called from the libraries (hence cann't put any brakepoints and thats why we could not debug the problem). Since I have removed the code my DllMain() of my libraries, it must be DllMain() of other (NI?) libraries or the the one inserted by the LabWindows CVI (which we do not have access to, but surely you must be knowing what it is) or the CVIRTE.DLL itself may be causing the problem. I think if you run the debug version of CVIRTE.DLL, you at least will see why it is generating the access violation.

I have added all my libraries inside the project. Remaining dlls are NI dlls or standard Microsoft Dlls. Make sure to copy the dlls in your search path (or include project path in the search path). If you could not execute the attached project due to missing dll, please let me know so that I can send you the missing dll. But this project will allow you to run the debug version of CVIRTE.DLL to investigate the problem.

Regards,

-Deshmukh

[bilalD]

I can't reproduce the problem with just cvi DLLs with CVI 8.0.1. I am attaching the project I used to test this. I don't have VC6, so I made the VC2003 project. The problem is reproducible in VC 2003 as well so that's not a problem.

One DLL is linked to the full CVI RTE. The other 2 are linked to instrup (this is the "Instrument driver only" setting under the target settings). This is similar to the setup you have. I tried changing the order of the libs as well, but I was still not able to reproduce the problem.

Can you try using this project to reproduce the problem?

Thanks

[Deshmukh]

Hi Bilal,

Thanks for your reply. Please let me know whether I understand you correctly:

• You did reproduce the access violation in the project I sent using VC2003
• But your example (in the earlier post) using VC2003 project does not reproduce the problem.

I could not test your project since I could not open your project in VC6. But I noticed that my driver DLLs do not have explicit DllMain() and DllEntryPoint() functions declared as you have doen in your driver dlls (I guess it is inserted by CVI when I build the Dll). Still it is very likely that it will not reproduce the problem because we also did not have this problem earlier (and as I said earlier, the problem appears only when the link order in the VC6 project is specific, (dll with CVIRTE depedency last in the library list)).

Finally I changed project settings in my driver dll to use 'Instrument driver only' (instead of 'Full run-time engine' earlier) which removed the dependency on the CVIRTE.dll and naturally got rid of access violation in the CVIRTE.DLL. (Note that I did not change single line of code apart from this setting). I still think there is some problem in the CVIRTE.DLL which you can investigate using VC6 project I sent earlier (using VC6.0 of course!).

Thanks,

-Deshmukh

[bilalD]

Hi Deshmukh

I did manage to replicate the problem with the project I posted here and have filed a bug report to the developers. The good thing is you have a couple of workarounds you can use.

Thanks for reporting this issue.