 |
||||
         |
    |
|||
|
 |
|||
|
|
||||
|
My problem: To be brief and concise - this dialogue box is magically appearing in a Visual Basic 2013 application I'm writing:
I've chased this rabbit down so many holes I've lost count, feel like I've sprouted whiskers and a powder puff tail, and expect Elmer Fudd to stare me down with a double barrel shotgun and say "Iwve got you now, you wascally wabbit!" I might have an answer. The really cool part is I've read so many articles on this particular error I have a strange feeling it might be the same answer for more than one bloodshot eyed software engineer out there desperately trying to fix this problem. Thus why I'm writing this, to maybe spare you a significant amount of debugging time. If you happen to be an end-user looking for answers when you startup your Windows 8 / 8.1 machine, when closing World of Warcraft, while scanning a document with your HP Scanner (hpqscnvw.exe), when working with Avid Pro Audio, when working with MyDVD, when playing games with Steam like Left 4 Dead 2, if you have Panda security software installed, or many different Adobe products, when accessing data from your Panda security software, or many other products - I'm sad to report your error might indeed be described here ... however you are powerless to fix it. If their product does what mine did, this might indeed describe a root cause and fix. But again, if you are an end user, you'll have to talk your way up the technical support food chain to someone that actually writes code for a living, get them to read this, and try what I've described here. What I've discovered is but one of literally hundreds of ways this error can occur. Or, stated plainly, even if this error describes your issues - this might not be the solution you are looking for. But then again, it might be! Engineers only beyond this point! My project - and yes, this will ALL be geek speak ... :A very short description: Something I used to be able to do in VBA directly by accessing the Crystal Reports DLLs that came free in the box with Visual Basic 6.0 and were callable from Access 2000 and Access 2003 no longer work in the Access 2007 / Access 2010 flavors of VBA. This code would automatically regenerate and refresh > 1000 Crystal Reports and export their data for my client at the push of a button. I did this long before "Crystal Reports Server" was on the market, and is certainly costs way less than whoever currently owns Crystal Reports licenses a copy of their server product. I say 'currently owns' because every couple of years it seems to change hands - I first used them when it was Seagate Software. It worked fine for many years, but my client wanted was forced to migrate to the newer platforms by evil people exploiting Server 2003, Windows XP, Office 2003, and Microsoft not fixing the latent defects, but that is the subject of another article. Trying to be cost effective, could I do what I did before without licensing the new server based Crystal Reports Server at $2500 a pop? My end solution was do keep what I was doing in Access mostly in tact but run an external program to run and export the Crystal Report against a known database and export the results. Crystal Report Export ("CRExport.exe") was my stand alone program, which is what ran and generated that pretty little error dialog box above. My VBA code iterates through the records and reports, runs whatever SQL queries need to run before the report runs, and now instead of calling a DLL to export results now calls an external EXE to produce its output. There are > 1000 reports in each dataset! Problem Definition:When the first set of 1000 reports were first run, everything looked fine. Second run, a Microsoft Visual C++ Runtime Library error dialog box appeared and stated "Runtime Error!" Not every time. In fact, out of the first 2000 spawns of this .EXE file, I it only appeared once. Every run was 1000 runs of this external EXE from within VBA / Access 2010, and sometimes it worked perfectly. Sometimes it generated the error once. Sometimes 2 or 3 times. So certainly a low percentage, but it stopped and required a button press to move on. Plus now I had a report that wasn't generated. Debugging
fun shell cmdToRun, vbMinimizedNoFocus It ran pretty well and was cool seeing all the programs spawning and dying, though I'm sure I put more stress on the system than it was happy with. I thought maybe this stress was causing the thread space exhaustion, so I changed to another method to spawn the EXE, one that would wait for the spawned program to finish before continuing on: wsh.Run cmdToRun, 0, True No sleep necessary as the final parameter (True) says "script execution halts until the program finishes." You can read more about the wsh ("Windows Scripting Host") shell command here. Same problem! Seemed less frequent, but I didn't exhaustively measure how often the error happened. Lots of web searching didn't tell me anything useful, other than lots of programs apparently suffer from this same problem. Not finding a solution elsewhere on the web is what prompted me to write all this up. Next, as a work around, I put in some code in VBA to detect if the report wasn't generated and if so re-spawn the external program. My hope was if the error happens, I can at least be sure to get the final output - though I'd have to be around to keep hitting 'OK' on the error dialogue box. Except that detect-output-not-there code never triggered! One time when the program was waiting for the OK button on the runtime error dialogue box, I looked and sure enough my program ran fine and exported the crystal report just fine. Really Big Clue!This was a very important clue - the error wasn't happening as my program was opening, spawning its internal threads (I'm amazed and horrified at how much overhead it takes to run a .NET application program), running the Crystal Report libraries, or exporting the file ... The problem is happening when the program is terminating! For years (as in "Since 1996") I've been working with various flavors of Visual Basic since VB 4 and exiting the program was almost always done with a close() or me.close() statement in the main form at the bottom of the code, or one can invoke that with an Exit button also in the main form. Seemed like it worked just fine here as well. I think that is the root of the problem! And the answer is ... Instead of closing the main form that way, I switched to Application.Exit() Problem solved. At least after about 9000 runs of the program. I hope this helps you! Final Words... If you found this helpful or not, please send me a brief email -- one
line will more than do. If I saved you a bunch of time (and thus $$),
and you wanted to show appreciation, sending a little love via PayPal or
an Amazon gift card is also very much appreciated!
|
||||
 |
||||
