DLL headaches - runtime error 216, 217 - solved!
Dave Lively
For anyone who may get a problem similiar to this in the future..
I had a DLL that suddenly stopped working. Effects were that on free, I
received a series of error messages:
EInvalidPointer msg = 'Invalid Pointer Operation';
Runtime Error 217 -
This is described as an EControlC exception in HELP, as in someone
pressed Ctrl+c to terminate a console app. This wasn't a console app and
I certainly didn't hit Ctrl+c.
Runtime Error 216 - EAccessViolation
I got runtime error 216 repeatedly until terminating the task via the NT
process list or Delphi.
Solution: Create a new project of the same name and add all your units
to it. Apparantly one of the project files was corrupt. ARGHRHAHRHGGH!!!
*******************************************************************
BORLAND: Checksum routines are EASY to write and implement; how about
sometime of corruption check on save/load in Delphi 4? I lost a week on
this problem.
Dave
--
~~~~~~~~~~~~~~~~~~
Dave Lively
Keil Software
** Opinions stated are not necessarily that of Keil Software.
Krasimir Stoyanov
Dave Lively wrote:
> Solution: Create a new project of the same name and add all your units
> to it. Apparantly one of the project files was corrupt. ARGHRHAHRHGGH!!!
Have you tried Build All?
Regards,
Krasimir Stoyanov
Dave Lively
I think I broke my build-all button rebuilding. Yes, I rebuilt it. It's
solved now; believe me, I tried *everything*. But the new project file
only took about a minute to put together and everything started working
correctly.
Wierd, but it's over. =)
Jeff Kohler
I had problem with the exact same solution. In Delphi 2.0, a
symbol remained in the symbol table even though it was absolutely
no where in the source code!
Creating a new project and rebuilding killed the bug. I've never
encountered the problem again.
I'll second your advice: when you are perplexed about something
you believe is in the tool and not your code, create a new
project from scratch in a different folder!
Dave Lively
=)
The thing that "bugs" me most about this is that Delphi never gave any
hint that there was something wrong with the project file set; even the
mysterious "Stream read error" would've been helpful.
I love Delphi, but now that it's a third-generation compiler (built on a
4th generation compiler - BC++), I think some error-checking is in
order. A checksum/CRC routine for binary data would be fantastic; hell,
I'll write the damn thing and send it along if necessary.
BTW - this brings a new thought to mind. Anybody know if it's possible
to write a plug-in for Delphi that would perform this kind of error
detection/correction? I'd pay for that.
Just a thought for those that have more time than me.. =)
D
Krasimir Stoyanov
Dave,
You know that the project itself is a source file - nothing hidden, nothing
binary.
As a solution for such problems deleting of the Delphi generated binary files
with the name same as the project name (*.res, *.dof ..... ) should be enough.
Deleting of the *.dcu files also is recommended.
After all these binaries deleted you will have only Pascal source code and *.dfm
files.
Restarting Delphi and Windows and reopening the project will be the last step.
No need to recreate the project.
I have had such problems and the above steps were the solution.
Regards,
Krasimir Stoyanov
Dave Lively
Well, ya know, you'd think so, wouldn't ya?
I tried all of that - no dice. The only thing that fixed the problem was
*recreating* the project.