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)
Related
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.
I have an odd intermittent crash that only occurs under some circumstances that I am having trouble solving, and I'm seeking SO's advice for how to tackle it.
The bug
At apparently random points, Windows shows the "[App] has stopped working" dialog. It is an APPCRASH in ntdll.dll, exception code 4000001f, exception offset 000a2562. Here's where it gets tricky: this only occurs when running the application under the debugger. However, the debugger does not catch this exception, and at the point where Windows shows this dialog, the IDE is not responding. This bug does not occur when running normally, i.e. not within the IDE debugger.
I can't reproduce it outside the debugger, so I can't run the program and attach when it's already crashed. I can't pause execution when Windows shows this dialog, since the IDE isn't responding. I can manually trace through lines of code to see where it occurs. There are several, and where it occurs is apparently random. For a while it occurred when showing a window (or new form), for a while when creating a thread.
Edit: I have tracked it down to the IDE: if I pause on a breakpoint and click the Thread Status tab, the program will crash immediately with the above dialog even though it is, theoretically, paused. In this situation, the IDE remains responsive. This is really weird.
More information
I have just moved my development environment to VMWare Fusion. The bug also occurs running a build from my old (native Windows) computer on my new computer; it did not occur with the same EXE file on that old computer. This makes me wonder if it is related to Fusion or something in my new setup.
I am running:
Windows 7 Pro x64 on WMWare Fusion 3.1.3 on OSX Lion 10.7.1, all fully updated. Fusion is running in "Full screen" mode on one of my screens.
A colleague running Windows 7 natively (not in a VM) does not encounter this issue. Nor did I on my old Vista computer.
Embarcadero RAD Studio 2010, fully updated (I hope; there are about five updates and getting them all in order is tricky.) I have DDevExtensions 2.4.1 installed, and the latest IDE Fix Pack too: uninstalling both these has no effect.
The application is written mostly in C++, with snippets of Delphi. It is 32-bit.
We use EurekaLog, but the exception is not caught by it either. (Normally, an exception would be caught first by the debugger, then by EurekaLog.)
Running a debug build (no EurekaLog, extra debug info etc, debug DCUs set to true) also reproduces it. However, the "Debug DCUs" option on The Delphi Linking page of the C++Builder project settings dialog seems to have no effect - I can't step into the VCL code and find the line that actually triggers the error.
Codeguard (which detects memory access errors, double frees, access in freed memory, buffer overruns, etc) reports nothing.
This has all the hallmarks of a memory corruption. It only appears when you run under a one particular environment, and occurs at a different location each time. Both classic symptoms.
The best way I know to debug this is to download the full FastMM and run with full debugging options enabled.
If that doesn't help then you are reduced to removing parts of code, one by one, until you can isolate the problem.
Another problem I have seen in D2010 is a problem when mixing local class definitions (i.e. class inside class) with generics. The code generated is fine but the debug DCUs are wrong and when stepping through the code the debugger jumps to the wrong file and dies shortly after. You don't seem to have quite the same problem but there are similarities in the IDE deaths.
Finally I would advise you to suspect your own code rather than VMware. It's always tempting to blame something else but in my experience, whenever I have done so, it was always my code in the end!
I hit a quite similar problem. I've also been developing a .dll and when I've set a breakpoint anywhere in my code, Delphi stopped at the source code line and the host-application crashed immediately.
Closing the "Thread Status Window" in debug layout "fixed" the problem.
I'm working on Windows 7 64-bit and Delphi XE3.
4000001F is STATUS_WX86_BREAKPOINT
In other words, it is INT 3, which was not handled by IDE.
Since it is raised in NTDLL - I would guess that this is indication of memory corruption in system heap. Remember, some Windows code would switch to debugger version when running under debugger. That's why you can not reproduce this when application is running as standalone outside of the debugger - because breakpoint is not generated.
You may try FastMM in full debug mode, but I do not think that it will help you. The corruption does not happen in your memory, it happens in system memory. Yes, perhaps memory allocation scheme will be changed - and your corruption will reveal itself in your code/memory... may be. Try use top-down allocations, try use SafeMM...
Another possible approach would be using Application Verifier.
See also:
Windows has generated a breakpoint
C++ error on Ms Visual Studio: "Windows has triggered a breakpoint in javaw.exe"
http://blogs.msdn.com/b/oldnewthing/archive/2012/01/25/10260334.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2013/12/27/10484882.aspx
Check the The projects dsk file and make sure it does not have a reference pointing to the wrong unit. The fix is to open the dsk in an editor and change the file location to the correct location.
The problem is this:
I have a project developed in Delphi XE on my laptop. When I run it on my desktop PC, I get a "stack overflow" exception on this line (I also used Writeln() on different parts of the code and just this line is the source of the problem):
S_List.LoadFromFile('Test.txt');
(S_List is a local TStringList which is created before this line)
But, when I run the same exact project on my laptop, it works without any errors or exceptions at all. The problem can't be the method itself, because when I change the whole part and write it again using 'TStreamReader', the same exception occurs. This time on StreamReader.ReadLine(). Also, I changed the file location, name, .... Problem still occurs.
It seems like a file system problem, but I don't have the slightest idea how this happens.
Any ideas? Can it be because of a virus or a malware?
P.S: Both (laptop and PC) have Win7 and Delphi XE. Also, both have 2GB RAM.
Edit: Just to be clear, my main goal for asking this question is not finding where the exception lies (that can't happen by giving 1 line of code, can it?). But, instead, how come this error is NOT consistant in different hardwares? What reason can that have? Also, how can I find what causes this inconsistency?
My guess, and guessing is all we can do, is that you have an uninitialised local variable. Or an object that you access after having freed it. I'm not sure how that leads to your stack overflow but almost anything is possible with such a scenario. As well as madExcept you should be using FastMM with full debug settings.
When someone has difficulty diagnosing an exception in a specific environment with a Delphi application I strongly suggest madExcept. It's free for non-commercial use, very easy to setup, and VERY helpful. Install it, enable it for your project, build a debug build, and deploy it to the problem machine. When the exception occurs, you should get a very detailed call stack of where the issue happened.
I would check this:
Is the test file identical on both computers
Do you have the same locale settings on both computers
If Delphi XE has components source, debug TStringList source, maybe there is a bug
As Nathanial suggested, use madExcept or similar library
Create simple program that will just allocate TStringList and load test file. If this works, bug is somewhere else in your code, if this fails bug is probably in TStringList
Check for duplicate DCU's and if possible do a full build of installed libraries and the application to see if the error persists.
This is occurring on 2 machines that are both running Windows XP Pro SP3, yet it runs OK on my development machine within in or outside the Delphi IDE.
Running Windows XP Pro. Exe compiled under Delphi 2010.
When I run the exe I get the Windows Reporting error "Neopos.exe has encountered a problem and needs to close. We are sorry for the inconvenience"
I know it is happening somewhere in the form create of the main form.
Application.Initialize; //Runs this
Application.CreateForm(TfmMain, fmMain); //FAILS HERE
It does not get to: procedure TfmMain.FormCreate(Sender: TObject); in the Main Form and I don't know how to track down this error and debug it.
What happens between: Application.CreateForm(TfmUDF, fmUDF); AND procedure TfmMain.FormCreate(Sender: TObject) in my main form.
How can I trace this to find out what the hell is causing the Windows Error.
Of course the Windows Error report contains a long listing of information. Where can I look in that to find the cause or at least a clue on the cause of the error.
This error has now stopped all development work (and ruined my weekend) so I urgently need to fix this.
The most straightforward route to take would be to include a product like MadExcept or JCL Debugger into your application, to get a full call stack (including line number) of the point of failure. We've rolled our own years ago, and it has been a tremendous help in situations like this.
One alternative, but lots more cumbersome, would be to generate a MAP file from your project, use MAP2DBG to generate a .MAP file, and use the Windows Debbuging Tools to get about the same information. This approach is a lot more hardcore, and only advisable if you really want to learn a lot about the internals of windows debugging (and enjoy working with arcane tools).
Another alternative would be to attach to the failing application from your development environment using Remote Debugging. Only applicable if you have a fair amount of control over the failing machines.
#user576639, here are some debugging ideas:
Look into the System's Event Viewer
If you got the exe has encountered a problem and needs to close chances are you'll find something about it in the System's Event Viewer. That should be your first step.
Any special DLL's required?
Do you need MIDAS.DLL?
Are you using an database engine? Does it require some sort of client library?
I'm talking from experience here: My development machine obviously has all the libraries I might need. Most of my clients also have most of those libraries because they have my software installed. At times I put out small helping applications that don't go throw extensive testing and they fail to work on SOME machines but work fine on other machines. Why? I used TClientDataset and forgot to include MIDAS.DLL with the application; Or the application is trying to access a Firebird SQL server but the user doesn't have Firebird client library installed.
Printer driver issues
Boy I hate Delphi's printer handling. Also hate buggy printer drivers, haven't made up my mind about what's worst. If you have something on your main form that might be requesting information about the default Windows printer (example: an REPORT) give this a try: Install an sane/simple printer and set it as the default printer. If the user has Office 2007+ installed, set the "Microsoft XPS Document Writer" the default printer.
I have seen bad printer driver + delphi issues manifest themselves with the "exe needs to close" symptom.
Prepare an special build of your application
If you got this far without fixing your issue it's time to create an special build of your application that's capable of providing more information. First of all I'd try adding this to your DPR file; Don't know if this is still useful for Delphi 2010 but it did help me see some early exceptions with a Delphi 7 application:
function HandleUnhandledException:integer;stdcall;
begin
Result := 1; // 1 = EXCEPTION_EXECUTE_HANDLER
end;
// and then immediately after "begin" in your DPR file:
begin
SetUnhandledExceptionFilter(#HandleUnhandledException);
// ... the usual stuff goes here
end;
Add some ShowMessage-s to your Main Form's code, in your OnCreate handler (if you have one), in your Create constructor (again, if you have one). If you're adding an ShowMessage to your Create destructor, make sure it's after the "inherited" call. This will help pin-point how far the loading of the form goes before it fails.
If all else fails...
Create a new, blank form; Make it the new Main Form (so it's initialized before your former Main Form). Test it on the client's machine - does it show up? It most likely will, if it doesn't you've got some serious problems.
Start copying the components from the former main form to the new main form; Only the components need to be copied, not the code: Your error is probably caused by some component failing to initialize properly. Make sure no component has "Active=True"! Copy the components in small batches, test often. If you spot the component that causes your form not to load on the client's computer, tell us about it and we'll try to help.
If you manage to get all your components on the new form, write an OnCreate handler that sets Active := True for all the components that need that. Did that fix the issue?
If you got this far then all the components you used on your main form can load properly. The problem's related to YOUR CODE. Start copying all the code from your old main form to your new main form, in small bits, and test. You're bound to find the peace of code that causes your application to stop loading.
Use dependency walker to see if you're missing a required DLL.
You can use information from system reporting (your error and suggestion to send it ) with Error Report Grabber ( http://www.maxerist.net/main/soft-for-win/err-rep-grabber ). I developed this tool when I desperately needed to track a error that appeared very rarely so almost non-reproducible. It helped me to track the information from stack to find actual place in the code.
The tool works only on XP (MS removed this dialog in Win7 and probably Vista), but I see that your cases are XP so this can help.
UPDATE: if you're not familiar with assembler and everything, this can work like this.
You should compile you program and don't change anything. Save the report on a bad machine, copy the file to your developer machine and open to view the contents. Look at the stack of your main thread in the report and find numbers more than $00400000, they're usually the addresses inside the procedures that called some other procedure and wait for return. In your developer machine, start the program and stop at any line, open CPU Window and on the main list with assembler instruction right-click and choose go to address, enter this address. You will see other assembler lines, but wrapped with pascal constructions you can probably recognize as yours
Thanks a lot for the help.
In the end I reverted to a recent backup and traced it down to a particular form.
I did not actually find the error, which is a bit worrying, but in any case I am back up and running (phew!!)
I made the error to occur on my development machine also, when, and only when, I use my install program (Inno Setup) to compile a setup.exe and which installs the exe as well as installing postgreSQL. Seems really strange, as though there is a problem with the setup compiler. In any case I have not seen the error again. I guess it will remains a mystery, like women.
In Delphi withing debugging options select debug dcu's, this will allow you to debug into the Delphi source code for TForm and its descendants and you may be able to track down a more likely culprit.
Set a breakpoint on
Application.CreateForm(TfmMain, fmMain); //FAILS HERE
and then step into the code to see where the issue is.
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.