Microsoft error report popup

[menchar]

We're getting a Microsoft error report popup that yields no easily useful information to localize the root cause.  We often see these when some poorly written code de-references a NULL or bad pointer.

Usually, we run a debug build of our application (without the IDE) to get a NI popup instead, that helps us localize the problem with a reference to the offending source code.

BUT, my minions are claiming they've run a debug version of our application and that they are still seeing a Microsoft error popup, not an NI popup.

Is this possible?  Doesn't a debug build catch every exception coming out of the executable code?  Could it be possible that an exception is getting past the check code in the debug build, and getting caught by the operating system?

Menchar

[AndrewMc]

Menchar,

I really cannot think of an instance in which CVI will not catch the error and at least display a General Protection Fault in lieu of a Windows "This program has encountered an error and needs to close" dialog.

Could you please describe in more detail when your "minions" see this message (at what point in your program)?  Is the message the "encountered an error" message noted above?

[menchar]

Thanks for the response.

When I asked again, they became uncertain that they were really running the debug version of the application.

I just wanted to verify that the debug build would catch all exceptions coming out of the app.

That's because I do know of a case where it doesn't work that way.  If .net runtime is active, there are circumstances where it, not the CVI debug executable/runtime, will catch the exception.

Menchar

[menchar]

More info.

We are seeing errors that abort a CVI application in debug mode, but the exceptions are not being caught by CVI.

The errors are occuring in a couple of places, but most often in the Windows RPC dll, rpcrt4.dll (!).  This is pretty surprising, we're not explicitly trying to do anything over the LAN that would require RPC that we know of.  We are using ActiveX to run Word to generate a WordReport.

We sometimes see the error in ntdll.dll

I've turned the Win XP SP2 DEP off for "all programs" so that it covers Microsoft stuff only.  You can do this with the control panel.

Also, I had been told by NI that the CVI RTE is single-threaded with the exception of the 8.1 rs-232 library that uses a separate thread to manage the output queue if one is specified in OpenComConfig.

However, using Process Explorer, I see two threads:

cvirte.dll!GetRS232ErrorString + 0x4c8

where cvirte.dll is the invoking module and GetRS232ErrorString is the thread function.  What's happening here?  Are these queue management threads?  We're using CVI 8.0 - I thought these were added in CVI 8.1.

I can't tell which thread is generating the exception.  It's not the main thread apparently, since the application keeps running despite the exception (which CVI debug build does not catch).

Do we know that the CVI debug build will catch exceptions from every thread within the application?

We are using a data recorder that uses a multi-threaded DLL, will the CVI debug executable catch exceptions coming from that DLL (the threads are within the application process byt were created in the third party DLL)?

Any light on this would be a great help.

Menchar

[AndrewMc]

Menchar,

Please try and narrow this down to a specific part of your application.  Try to identify common attributes associated with the exception each time it comes up.  If I were to guess among all of the aspects that you brought up, I would suspect that the Word ActiveX would be a likely culprit.

[menchar]

We had updated the app to use the latest version of WordReport.fp.  Previously, the app was being built with old versions of WordReport.c, .h, .sub, and .fp, and Word2000.c, .h, .sub, and .fp included in the project. 

We ripped these out and went with just the WordReport.fp included in the project.  We did this on four different variants of the application.  We have no problems except for the oldest app.

Maybe we've discovered why the original author was putting all of these files into the project instead of just the .fp.  Could be it's doing something not quite right with WordReport that the other variants of the application avoid or have corrected, they were writen later.

We can't correlate the problem to any particular version of Win XP, or of Word.

It's going to be hard to localize this, since the exception isn't coming from a thread that CVI can hook, it looks like to me. 

Menchar

[menchar]

Should I be using this function to catch exceptions in the Word automation?   Will using this function cause CVI to catch an exception being raised in the ActiveX object that wouldn't be caught otherwise?

SetBreakOnFirstChanceExceptions

LabWindows/CVI ActiveX Server Interface

CVI_AppSetBreakOnFirstChanceExceptions (CAObjHandle objectHandle, ERRORINFO *errorInfo, long enabled, long *returnValue);

Note  This function signature is shown as it appears when you create a client using the LabWindows/CVI ActiveX Controller Wizard. If you create a client for the LabWindows/CVI ActiveX server interface using a different development environment, this function might be exposed differently. Some of the parameters documented here, such as objectHandle or errorInfo, are not applicable if you write a client using a different development environment.

[menchar]

Why isn't there a    WordReportSetBreakOnFirstChanceExceptions (CAObjHandle objectHandle, ERRORINFO *errorInfo, long enabled, long *returnValue);

function in WordReport.h ?  Or something similar in Word2000.h?

It would seem that there should be per the CVI help file.

Menchar

[menchar]

Now we're seeing the error popup in one of the newer applications as well

Originally, the code did a whole lot of operations to set up a page in a Word doc and write a lot of stuff into it, then save the doc with

WordRpt_ApplicationNew (VFALSE, &appHandle);

WordRpt_DocumentNew(appHandle, &docHandle); 

...  lots of WordRpt calls here ...

WordRpt_DocumentSaveAs(docHandle, dataPackFileName);  

WordRpt_ApplicationQuit(appHandle, 0); 

then restart Word, reopen the doc, add a bunch more stuff, then

WordRpt_DocumentSave(docHandle); 

WordRpt_ApplicationQuit(appHandle, 0);

and do this a couple more times, then finally

WordRpt_DocumentSave(docHandle); 

WordRpt_Print(docHandle, "", WRConst_PrintAllDocument, 0, 0, 1); 

WordRpt_ApplicationQuit(appHandle, 0);

We were getting Microsoft exception popups before the doc was saved the first time.

We put a WordRpt_DocumentSaveAs ( )  close to the start of processing as opposed to the end of the first pass through, and we added some WordRpt_DocumentSave ( ) calls throughout to periodically save the doc, so that we might localize where it was blowing up.

And of course, it doesn't fail now

Menchar

      

[Ian.W]

For what it is worth, I'll mention that a few years ago we had weird problems putting a lot of material into Word from a CVI app via DDE. (specifically Word 2002 & XP; and no ActiveX - just basic DDE).  My memory is a little foggy on the details, but the problem seemed to crop up when we exceeded a certain threshold of the number of bitmaps we pasted into the Word document.  Narrowing it down was difficult and inconsistent, and depended on reboots, and the takeaway was that it was probably some memory management issue in between Windows & Word. We had some NI people in on the troubleshooting.  In the end we simply limited the size of our Word files to dodge the problem.

If this seems like it is related, I could do some digging and provide more details.

Good luck,

Ian