• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2925
  • Last Modified:

External Exception C0000008

I'm trying to use a third party library tool (DLL library) to convert a file from HTML to RTF.

When I call the method in the third party library to convert, say document X to document Y, an external exception C0000008 is raised.

Now normally, I would blame the third party library - BUT - when I run their demo application to convert the same file it works fine. I have the source to their demo application, and I copied the exact way in which the convert method is called, including all preparation leading up to this.

The two methods are identical. However, when called from our application it always crashes.

The compiler options for their demo app and mine are identical. I even increased the stack size of our application to a ridiculously large number, but still the error occurred.

I've found no definitive reason behind the ...008 exception on the Net. I wondered if anyone else knew a  potential cause for this. Also what other things could I try to get around this? I could always go back to the vendor of the library, but they're going to say," well it works with our demo app..."

P.S. I was previously using FastMM,  but have since disabled this. Still no joy.



  • 2
  • 2
1 Solution
 Most issues I run into while using external DLLs come from a stack misalignment due to the parameters of the function definition being different than the actual parameters of the function. Check them closely.  It may be that the function definition you are getting in your application is in a different location than the one the demo app uses.  Go into each application and [CTRL] click on the unti name.  When the unit opens, try to do a SAVE AS and see if they are in different places.  One may be an older vserion.

Let me know.
steve-westAuthor Commented:
Thanks for this.

There isn't any inconsistency between the library headers used by the demo app and our own one. It's the first time I've tried integrating this product into our own, so there aren;'t any duplicates hanging around.

I am able to use some of the functions in the library, it's just that the big daddy of them, the one that actually does something SOMETIMES doesn't work.

Basically, the library converts HTML to RTF (and back again). For most documents this works OK, but for one test example, it doesn't. In the demo app it does perfectly, but not in the core application - it always fails at the same function call.

What I did try was to create a simple application which called the same code shared by the core application  which used the functions within the library. This worked fine, so at least there isn't a coding issue - in some ways I wish there was.

I don't know what else to try. The core application is HUGE - I can't possibly keep hacking chunks out of it hoping that somehow I'll kiss life back into this area, because I'm still going to be non the wiser that if I do reach a point where it does begin to work, why it has started to work and how to put back all the lopped off pieces.

To be fair, the guys who support the product have  been great, but they don;'t expect to find the cause of the problem, if they can't reproduce it and, being a developer myself, I 100% appreciate this. It doesn't help me though.


 Does the problem always occur with the same HTML file?  Are you able to reproduce this?  I would start by listing the calls to the function that is failing.  Log all parameters of each call.  It may also help to log the SizeOf each parameter as well.  You will need to see a pattern, at the very least, if you hope to find the cause.

  If you can run the same test set and cause the error each time then you will need to see if you can use the same test case and reproduce the error in your simple application.  If you are able to cause the error in the main app and not in the simple app then it would indicate that the main application is at fault.  

  When I have found this kind of error (caused by something in the background of the main app) in the past it was usually a memory overwrite type of situation.  This will cause a corruption of the data you are passing to the other control (if not overwriting data within the DLL itself).

  When debugging a large application in the past (one where there was no apparent cause in our code) I had to resort to what I wound up calling "Binary Deconstruction".  The application was causing a runtime error after the end statement in our code (and all of the finalization sections), after control was handed back to Windows.  I removed roughly half of the program's code from my project and got it to recompile.  The error was still there.  I continued removing half of what was left until I found out that the error was still happening with only the main form left in.  I then started removing half of the controls in the same manner.  What I found was a known Windows bug that happened only when using an ImageList and only if an image in the list was over 64k.  It had nothing do to with my code, but I had to find it anyway.

  Unfortunately you may need to roll up your sleeves and do some serious debugging here.  While the error could be (and likely is) in their code, the cause of that error is usually in yours.  At least by doing a Binary Deconstruction you can cut the code down rapidly.

Let me know if you make some progress on the debugging and could use more sepcific help.
steve-westAuthor Commented:
Thanks again for your suggestions.

I've just spent a fruitless 4 hours performing hack-amania on the application. This application is a beast and I've reduced it to the smallest footprint I can. Any smaller and I will have to run through modifying almost a thousand components, which is not even worth considering.

I started by placing a call to the conversion routines at the very start of the DPR, but this crashed.

I then removed the contents of the DPR itself - no main form, no application initialise, and this worked.

I then placed a reference to the uni holding the base form - this is the form from which all other forms descend. This caused the conversion to crash.

I then went through and removed via compiler directives all COM access, third party libraries, socket functionlity, hashing and caching algorithms.

From experience PChars are a prime candidate in circumstances such as these. Alll pChar usage was therefore removed if possible and double checked if not.

Still I have this problem. No form instances are being created - the DPR does nothing other than call the conversion process. All initialisation sections have been checked and any that are able to  be removed, removed.

I then prepared to send this cutdown app to the library's vendors, to see what they could make of it. After compiling the project, delphi duely crashed, so I had to close the editor.

Anyway, I ran the program to see if it would crash as expected, but this time it worked!

I opened delphi, ran the program and it crashed. When I ran the program from explorer, it crashed. I closed down delphi, ran the program from explorer and it worked.

It seems that it the delphi bds is open, then the application crashes even if it's run outside the IDE.

Bloody strange and this has taken me the best part of a day to find.

Anyway, thanks for all your help. Still no idea why the library + delphi = crash but at least I now know how to work around it.



Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now