It used to be that if an exception got raised and propagated far enough up the call stack, Application's main loop would handle it and give you a dialog box. That behavior seems to be broken under Windows Vista. If any exception reaches that level, Vista steps in and says the program "has stopped working," when it used to be perfectly able to continue under XP. (That's the entire reason the exception handler in the main loop is there, for heaven's sake!)
Is there any way to fix this? Preferably in my code itself and not just on my computer, so it won't screw up on other systems?
Check to ensure that the global variable in System, JITEnable is still set to 0. If that variable is set to 1, hardware (and external) exceptions will cause that behavior by calling UnhandledExceptionFilter. If it is set to 2, any exception will cause it.
You should add an application level exception handler, http://www.chami.com/tips/delphi/011497D.html. Also you should look into running madexcept to determine why these exceptions are happening, so they can be fixed.
Unfortunately, not all exceptions were nicely caught, even in XP. Ever had an application just vanish, ot just hanging and needing a pskill? (some Delphi version anyone?)
I would try to plug EurekaLog in your app and see if it gives some information on what happens.
Related
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.
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.
I have a random Runtime Error 216 that appears on application close.
I have debugged as far as I can and the error is thrown in SysUtils.FinalizeUnits.
I have gone over the code and ensure all created objects are freed.
The number on the runtime error, 0040054A, is not present in the mapfile. Do you know what this means?
Can anyone tell me how to find out what is throwing the error?
This is VERY OLD Delphi problem - wrong exception handling in unit initialization/finalization process.
The problem easy to reproduce - just make any program error/exception (division by zero for instance) in initialization block of any unit. The exception will be created correctly. But then, before the exception rise, the unit finalization process destroy the exception object. And thus, when the exception object accessed, the "runtime error 216" occured.
I'd suspect a memory leak (all Runtime Errors 216 I've encountered so far were) and use a profiler (visual inspection is never as good as a tool). Since you're using Delphi XE, you should give AQTime a try (it's included), see also
Delphi - Check if memory is being released "on time"
Kind regards, Frank
Since runtime error 216 is an access violation, this may indicate that you're attempting to use something that you've already freed.
Addresses in the map file are based at 0, but that's not where your EXE file gets loaded into memory. Your EXE gets loaded at its preferred base address, which is usually $400000. Subtract that from the address you have. The address you're looking for in the map file is $0000054a.
There was a similar question, Read:
How to debug a crash that only occurs on application shutdown? (Delphi)
Consider using Memory profiler, this may help identifying live objects after app was terminitated.
I suggest you try the FastMM Full Debug Mode, and either statically link that into your app, or use it as a package (if your app uses packages).
You can use the method I used to fix mine.
I commented out the main program, and added code back until it failed.
Turns out that it did not want me to call couninitialize at all. Did not throw an error at the time, but failed after program termination with a 216. Removing the offending statement fixed it.
Since this was maybe 6 statements before end. statement, I don't imagine it will matter.
This method is easy if you are consistent about using // for comments. I moved IO statements that needed curly brackets to a procedure.
On Microsoft's oficial web site it is mentioned that, this issue can occur if your computer is infected with a SubSeven Trojan virus.
Antivirus software and windows registry cleaner should help.
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.