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
There are > 1000 reports in each dataset!
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
"Program <my .exe name>"
"R6016 - Not enough space for thread data"
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.
I did a few things to see what might be happening. At
first, I was spawning the external program with:
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
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
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.
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!
answer is ...
Instead of closing the main form that way, I switched to
Problem solved. At least after about 9000 runs of the program.
I hope this helps you!
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!
I can be reached at:
das (at-sign) dascomputerconsultants (dot) com
(C) 2014 DAS Computer Consultants, LTD. All Rights Reserved.