I've problem with exception dialogs: I'm using RemObjects SDK for Client/Server -application. When there's connection problem, the client starts throwing "simple" exceptions dialogs, just text and a button. When I'm running the application on my development machine the exceptions dialogs are not shown (as expected). The text on the dialog is simple "Timeout", "Connection refused" etc. That kind of exceptions are raised AND handled inside RemObjects code inside worker thread. I've also EurekaLog activated, but it doesn't help at all.
Any ideas why it works on development machine, but not on "vanilla" client machine? How I can get rid of all exception popups?
I've following
Delphi 2007
RemObjects SDK "Winter 2009"
EurekaLog 6.0.22
I would do the following:
compile your app with debug info (.map file) and copy both to the client
start your app on the "vanilla" client machine
wait till a popup appears
start my sampling profiler:
http://asmprofiler.googlecode.com/files/AsmProfiler_Sampling%20v1.0.6.12.zip
use the "Stack view of process" button and choose your app in the process list
double click or press the "Live view" button
http://code.google.com/p/asmprofiler/wiki/ProcessStackViewer
you can now view the stack of the main thread, so you should see where the popup comes from...
Good luck!
You're going to have to do some debugging. If it's handled inside the worker thread, then it won't raise that dialog. Something's happening that causes the exception objects to escape to a higher level of the call stack.
Try installing on a vanilla machine of your own and trying to reproduce it yourself. You might notice some detail that the client didn't notice or didn't bother to report to you. Once you're able to reproduce it, you can try to figure out what's causing it with remote debugging or a handful of other ways.
A first step would be to use the remote debugger and start or attach to the process on the client machine.
You may have the IDE set to ignore these exceptions. You can check by looking in the debugger options. See Menu Tools/Options and then look in Debugger Options/Language exceptions.
If so, you can uncheck the option to get the exceptions back on the development machine and then use try/except to handle the exceptions programmatically.
Related
I have the community edition 10.3 of Delphi on Windows 10 and trying to use the JEDI (JVCL v3.50) TJvHidDeviceControllerClass (v 1.0.35) to control my HID device in a VCL form application.
This exception also gets thrown when I start up Delphi and when closing it down showing a dialog, provided that the component is already present on the form when loading the project. When ran with the OnDeviceCreateError() event handler assigned, the application behaves OK as I set the debugger to let the application handle this particular exception and setting the "Handled" boolean to true inside the OnDeviceCreateError() handler. It also works fine when run outside the Delphi GUI.
I have been searching for clues about fixing this issue and have seen that other people have encountered it as well. As most of the posts about this is quite old I wonder if I don't have the correct version of the library (https://github.com/project-jedi/jvcl).
The JEDI library was fetched from github just a week ago using the instructions on the readme page. My local repo was cloned from the master branch. I built it and installed it locally with no hassle.
Albeit working fine when running the application this exception is a bit of a nuisance as it messes with the Delphi GUI itself during startup (the exception dialog is shown, parts of the GUI goes missing after clicking OK).
I don't think that my code is the culprit here as the problem presents itself before any application code has even begun executing. I suspect that Delphi itself runs the constructor for the component before the OnDeviceCreateError() handler has been assigned and so the exception propagates all the way up to the GUI during palette placement or startup. Why the exception shows while shutting Delphi down is harder for me to explain.
Is there a fix to this or a setting to prevent Delphi running the constructor at design time?
Should I create the TJvHidDeviceControllerClass instance during form creation instead?
Thanks in advance /Thom
After some trial and error I worked around the problem by removing the component from the form designer and adding the TJvHidDeviceControllerClass manually with method bindings to the class in code instead.
The default constructor should not be used as it does not bind the exception handler at create time. Use the other one that does the binding.
It now works fine without stray exceptions at start/stop times.
When creating manually, be shure to explicitly free the TJvHidDeviceControllerClass object instance at form close.
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.
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.
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.