When I open a form, I am suddenly getting an error message:
"Error reading form: 'X' "
Cache is not initialised. Must call TCache.Initialise first. Ignore the Error and continue? NOTE: Ignoring the error may cause components to be deleted or property values lost"
The "Cache is not initialised" bit is an exception raised by one of our classes.
My first question is, why is the Delphi IDE running my code without me asking it to "Run Program"? What code does it run? Is there any way to turn this off?
Secondly, is there any way I can trap this error in the debugger, so I can work out where in the call stack this exception occurs? I have tried putting a breakpoint where the exception is thrown, but Delphi ignores it.
And also, once I have worked out where this exception is coming from, is there a way to tell when I am in "design mode" and not run that code, or run different code? Or even better, not run that code at all if in design mode?
[Update: See Francois' answer to how to stop code running in design mode.]
You have some component code that you wrote that is executed when the IDE is trying to load the dfm.
You can test in your code if your component is in "design mode" with
if (csDesigning in ComponentState) then
When the IDE loads a DFM, it creates live objects within the Form Designer, which means component run-time code is actually run within the IDE. As such, component code needs to check the TComponent.ComponentState property for the csDesigning flag if it wants to skip running portions of its code at design-time.
Related
While testing my delphi application, some Exceptions are raised but the debugger is not showing where (like it used to). Is there a setting which is causing this?
EDIT: When an exception occurs, a message appears alerting me to the fact that an error has occurred and what type of exception it is. Normally, I would be able to click 'break' and it would show me at which line the error had occurred, but when I click break, this doesn't happen.
It might help if you post a screen shot of what you actually do see before and after clicking Break.
And you haven't really answered the very first comment on your question: "What errors are occurring?" The point is if it's specific exceptions that aren't showing the code - they may be occurring in an external DLL.
As a first step check if Delphi will show the exception in the most simple case:
Drop a button on your form.
Write an OnClick handler with the following code: raise Exception.Create('This is a test');
NOTE Make sure you try this in both your existing app, and in a brand new stand-alone app.
If Delphi doesn't show you that exception in the simple app, I'd be very surprised, and some more serious digging will be required.
If it is shown in the simple app, but not in yours, then there's some specific problem in your project:
Ensure you aren't disabling debug info {$D-} or {$DEBUGINFO OFF} somewhere in your project.
You might have exception hooking code in your project that is somehow interfering. Try disabling exception loggers and similar tools to narrow down the problem. (Don't forget to re-enable the appropriate tools once the issue is resolved.)
Verify that your search and browsing paths are correctly configured to find the source code in order to show you the error.
If the simple exception is shown in both apps, then we'll probably need to know exactly what exceptions aren't showing to help further. However, here are a few more pointers (^s):
Go to Tools | Options. Under Debugger Options, look for Native OS Exceptions. Verify you haven't changed any of these settings.
When the exception occurs, open your Thread Viewer, and check if the the exception was raised on the main thread or another thread.
Also open your Call-stack Viewer, and verify you actually do have a call-stack.
Then check if Delphi will show the code for any of the call-stack lines.
NOTE There is still the possibility that Delphi is simply unable to find the source unit depending on where the exception is raised. However, Delphi is supposed to prompt you and ask where it can load the file from in such situations. (It definitely worked in older versions of Delphi.)
But I wouldn't rule it out because a buggy plugin might well be suppressing the prompt.
You can control the reaction of the debugger on exceptions from within the options.
Go to Tools\Options.
Click on the Debugger Options, then on language exceptions.
You probably have unchecked "Notify on language exceptions".
Else you can enable as much as possible.
Be sure to enable all debug information in your project:
Debug information
Symbol reference info
And try without optimizing.
I have seen other questions with this same problem on XE Forums, but still no answer. I run my application from with the XE IDE and I get an EOleSysError - 'The system cannot find the path specified'.
But, I can go out to explorer to the same directory and run that same app outside the IDE and it runs fine. No errors. All of my assemblies are located in the build directory of the application, so I'm not relying on GAC or anything, just directory the executable is in.
Is this a known bug with XE and Windows 7 x64?
Is this a path problem? Environment variable issue? It almost seems like the IDE is running my exe from another directory, but the exe is only being compiled in one place.
Any help here would be appreciated.
Thanks,
Rick
It's not a bug at all. The debugger is catching the exception, and letting you know about it before it passes it to the exception handler in the code. It's working by design, letting the developer know that the exception happened.
If you want to avoid this happening, you can do one of a few things:
(Easiest) Set a breakpoint on the line immediately before the exception is raised. Right-click the line, and choose Breakpoint properties from the context menu. Click the Advanced... button, and then uncheck the Break checkbox, and check the Ignore subsequent exceptions checkbox, and then click OK to close the dialog. Set a breakpoint on the line after the exception is raised, and repeat the process above, except this time check the Handle subsequent exceptions checkbox. I say this is easiest because you can disable it to break on the exception simply by disabling the breakpoints, and remove it entirely by just removing the breakpoints, and you get a visual indicator that something is different for that block of code.
Disable IDE error handling for all EOleSysError exceptions, from the Tools->Options menu, find Debugger Options->CodeGear/Embarcadero Debuggers->Language Exceptions, and add EOleSysError to the Exception types to ignore dialog, and make sure the item is checked. It's the way Indy's exceptions are prevented from stopping the debugger, for instance.
Just click the Continue button in the exception dialog, and let the code keep running. This gets a little annoying sometimes, such as when you're running code in a loop, and something in the loop is raising the exception; you keep getting the dialog over and over again.
can somebody help me out with this error
Project1.exe faulted with message: 'application-defined exception (code 0xc0000008) at 0x7c90e4ff'. Process Stopped. Use step or Run to continue.
Using Delphi 7 on Win XP. Installed are ony default original Delphi 7 components. I have only a button and opendialog component on my new fresh project. I am using just one line of code in ButtonClick procedure
OpenDialog1.execute;
when this warning on picture occurs. Open dailog shows up for milisecond then Delphi error is reported before I can choose anything from open dialog.
What could be wrong? This behaviour is new, because I used opendialog before without problems.
TIA
P.S.
Program runs OK outside of Delphi IDE.
P.P.S.
I deinstalled GExperts, DelphiSpeedUp but problem remains.
Looking around online, I see that this error seems to happen every now and then. I don't know the real reason, but it seems to be related to the debugger. I'd guess it is some kind of obscure debugger bug that only happens when many different things come together.
FWIW, I've seen reports from D4 to D7 and even D2006. It seems to be gone in higher versions, although that is not sure.
The more reports I see, I notice it always seems to happen in the Delphi debugger. More evidence that it is the debugger, IMO. If that is the case, there is not much you can do.
Your problem could be an Explorer addin that is throwing an exception.
It could be something that adds things to the file context menu, like Tortoise SVN (as an example, I'm not saying that's the culprit), or it could be something creates previews for files or even a trojan or adware.
The file open dialog uses the same code as Explorer to display the file list, so any add in that you have for explorer is also loaded/used for the file open dialog. In explorer, it might throw the exception but not kill anything, but in your program (whilst running in the debugger) you can see it.
How to fix it? Try uninstalling any explorer addins that you know about... If that doesn't work, maybe do a scan for adware and trojans.
Set a breakpoint on the line of code that is crashing. Go into the debugger (run the app).
When you hit this line check these things:
Evaluate expression Self and make sure it is not nil.
Evaluate expression Self.OpenDialog1 and make sure it is not nil.
Also, look for code that frees (destroys) the objects you are working on. If you truly have written no extra code, and have a completely new empty application, then it is very hard indeed to understand how you could have a problem like you describe, on a new fresh project.
Same problem occurred in the office here.
The person facing the problem told me he managed to work around it by telling the debugger to leave error 0xc0000008 up to the app to handle.
/options/Debugger Options/Embarcadero Debuggers/Native OS Exceptions/32bit Windows OS Exceptions/
It occurred with the following configuration:
Windows XP
Rad Studio XE (Delphi)
Just installed Amazon Cloud Drive
I moreless had the same problem with D2007 running W8. I moved the code to and old WXP machine and the program ran fine both inside and outside Delphi. In our case, just for reference, the program reached two times the code that raises an Edatabaseerror
procedure DatabaseError(const Message: WideString; Component: TComponent = nil);
begin
if Assigned(Component) and (Component.Name <> '') then
raise EDatabaseError.Create(WideFormat('%s: %s', [Component.Name, Message])) else
raise EDatabaseError.Create(Message);
end;
After debugging I discovered that the infamous error was created by Delphi as a noncontinuable exception after the Exception.Create constructor but why, remains a mistery
I also tried the proposed solution of leaving the debugger handle the exception but was useless since in our case the exception number changed every time
First of all - sorry for my English.
I get the same error on the same Delph7.
In my case this error was raised by recursion)
When an application is run from within the IDE and the debugger is attached the exception 'External exception C0000008' is raised when it tries to connect to an imported ActiveX control.
If the application is ran standalone or the Rad Studio options/ Debugger Options/ Integrated debugging is unchecked, the program works as expected, no exception and the ActiveX control returns the expected result.
There are other ActiveX controls in the project, all of which work fine.
I have tried:
- Reinstalling the ActiveX control
- Re-Importing the ActiveX control
- Removing any software that may be causing conflicts (experts/ plug-ins etc)
- Turning off most running applications and services etc in case they are causing a conflict
Searching Google, It looks like others have been experiencing the same problem, but there is no fix to be found (other than turn off Integrated debugging, but obviously that is not a valid option.
Does any one have any ideas were to look to fix this problem?
I am using Delphi 2007
C0000008 is the status returned for an invalid handle. Make sure that your wrapper when it goes to create the object gives it a proper handle and not nil (assuming it is crashing because of a windows handle).
Since the application runs fine when not attached to the debugger, I'm assuming that the wrapper is handling this condition gracefully so the error is most likely occurring inside a try/except block.
It's a combination of non-obvious function behavior and IDE options.
MSDN CloseHandle
If the application is running under a debugger, the function will throw an exception if it receives either a handle value that is not valid or a pseudo-handle value. This can happen if you close a handle twice, or if you call CloseHandle on a handle returned by the FindFirstFile function instead of calling the FindClose function.
So there's two options - either check the code for a place where some invalid handle is being closed or turn off IDE's notification of this exception. Go to Tools > Options > Debugger options > Emb debuggers > Native OS exceptions, find Invalid Handle item and change On resume option to Run handled. This worked for me.
Credits for this solution go to _Vasilisk_ from sql.ru forum.
I opened a project (created in D2007/08) in D2009 and it would compile but throw tons of exceptions when executed. Strange thing, but I know the project's a mess, so I want to go ahead and fix it. Well, not really fix all of it, just make it work would be enough.
When I ran it, I got some Debugger Exception Notification (the little message dialogue with Break, Continue, Help buttons) and I wanted to proceed and see if would perhaps work when skip over the exception. I checked the little "Ignore this exception type" check box in the bottom left corner and clicked Continue. Now I no longer get the Exception Notification, but the application still doesn't run. I just get a couple of vague error boxes and have very little idea what's going on.
I would like to re-enable the exception type I previously selected to be ignored. But I can't find the option anywhere. Where should I look for this? Can anyone help?
I have found the ignored exception types in
(Main menu) Tools >> Options >> Debugger Options >> CodeGear Debuggers >> Language Exceptions >> and there is the list of exception types ignored.
It's somewhat more hidden than in D2005 but very close to what was said in the article referenced by Stuart Dunkeld.
The following is extracted from this page on the Delphi Q&A by Rob Kennedy: (CC licensed) although it relates to Delphi 2005 it may help.
Why do I continue getting error messages even after I have written an exception handler?
In its default settings, the Delphi IDE notifies you whenever an exception occurs in your program, as in Figure 1. What’s important to realize is that at that point, none of your program’s exception-handling code has run yet. It’s all Delphi itself; its special status as a debugger allows it to get first notification of any exception in your program, even before your program knows about it.
Avoiding notification
If you do not want to be notified when an exception occurs, you have a few options.
You can use Delphi’s “advanced breakpoints” to disable exception handling around a region of code. To begin, set a breakpoint on the line of code where you want the IDE to ignore exceptions. Right-click on the breakpoint dot in the gutter and open the breakpoint-property dialog. In the advanced section are some check boxes. (See Figure 2.) Clear the “Break” box to prevent the debugger from interrupting your program at that line, and set the “Ignore subsequent exceptions” box.
Afterward, set another breakpoint where you want the debugger to resume handling exceptions. Change its properties to handle subsequent exceptions.
You can tell the debugger to ignore certain kinds of exceptions. Figure 3 shows Delphi’s language-exception options. Add an exception class to the list, and all exceptions of that type and of any descendant types will pass through to your program without Delphi interfering.
In an option related to the previous one, you can tell the debugger not to interrupt on any exceptions. To do that, clear the “Notify on language exceptions” check box.
Finally, you can turn off integrated debugging altogether. Delphi will not notify you of exceptions, and it will also not stop at breakpoints or allow use of the “Pause” button. Turn off integrated debugging in the debugger options, as shown in Figure 5 for Delphi 2005.