Make a Delphi 2007 application, TForm as main window.
Run application. Try to drag the form using the caption bar. The debugger shows an unending stream of error messages, complaining it can't find some unnamed routine. Escape and Break don't work. 3 finger salute doesn't work.
Clicking in some other window and then back to the Delphi application stops the avalanche of error messages and allows the application to function in its original location (the form itself hasn't moved).
Strangely, on occasion I've had related behavior using Firefox -- clicking in the browser window doesn't work 'til I click in some non-Firefox window, after which the browser window is active again.
Anyone seen related behavior? Suggestions? Might it be a mouse driver problem? Toshiba laptop with ALPS touchpad mouse.
This doesn't sound related to Delphi specifically. The "stream of error messages, complaining it can't find some unnamed routine" sounds very odd. Could you post one or two of the actual messages, please?
In the meanwhile, my guess is some form of hook or injected code. Try looking for programs that do that kind of thing and disable them one by one:
Mouse drivers (as a poster above
said)
Antivirus, especially the "big ones"
like Norton etc
Some display driver "enhancement"
utilities
If you have two screens and you're
running a second taskbar program, try
that
and so forth.
It's probably worth doing a virus scan too, you never know :)
I know there was a Logitech driver hook problem when starting a Delphi project in Delphi: it gave an exception on the first line of the .dpr. Outside Delphi it worked OK.
So do you get those exceptions/problems only in Delphi? What kind of error/exceptions?
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.
I am experiencing a crash / exception when using a simple TOpenDialog with VCL Styles enabled.
Without the styles enabled, the dialog is of course working fine. The issue occurs with C++ Builder 10 and 10.1 Professional.
To reproduce:
create a simpe VCL Form that uses styles
add a TComboBox, a TButton and a TOpenDialog to the form
add the following code to the OnClick event for the button
OpenDialog1->Execute();
for(int i=0; i<100; i++)
ComboBox1->Items->Add("test text");
ComboBox1->ItemIndex = 1;
run the application, click the button and select a file
For me, this yields to an exception 'Out of system resources'
This bug could be reproduced on Windows 7 Enterprise and Windows 8.1 Pro.
Having the same issue with a TSaveDialog.
The weird thing for me is that regarding this exception, I can't find similar issues on the web. In my opinion, with only VCL styles and TOpenDialog required to have this, I would expect more information about this on the web.
I only found something remotely similar, but not an exception there and also no solution in terms of native VCL styles:
Using custom styles shows invalid characters when right-clicking a file in TOpenDialog
I tried also to disable SystemHooks shDialogs (please see screenshot) which I read somewhere regarding another problem with VCL styles, but to no avail.
* Edit 2016/05/26 *
Remy Lebeau is asking for a MCVE. I tried to put everything in the question, but for clarity here an abstract for a MCVE:
create new VCL project with default settings
drop a TComboBox, a TButton and a TOpenDialog into the form
add the following code to the OnClick event for the button:
void __fastcall TForm1::Button1Click(TObject *Sender)
{
OpenDialog1->Execute();
for (int i=0; i<100; i++)
ComboBox1->Items->Add(L"test text");
ComboBox1->ItemIndex = 1; // <- exception occurs here
}
enable a VCL style 'Smokey Quartz Kamri' in the project options
run program, press button, select any file and select OK in TOpenDialog
Here, this is really all it takes for the exception.
In my opinion, the call to Execute() messes up some VCL structures (only if styles are enabled) and then the access to another VCL item (combobox in my case) leads to the crash.
I am now aware that not every one has this crash. So forgive me if it is not a 100% verifiable example for each of you.
But me and my colleague can't be the only ones who have this crash (tested now on 4 different computers with 3 different OS versions), can we?
* Edit 2016/05/27 *
Regarding Tom Brunberg's request for single step, the exception occurs somewhere within WndProc, in the screenshot at address 005459F4 within the call.
If I step further, I am landing somewhere in TCustomCombo.WndProc. After that is is very hard to follow further because of repeating loops in WndProc, can't seem to reach the final place where the exception fires.
* Edit 2016/05/27 second *
OK I managed to pinpoint the exact location of the crash. Is in in the function CopyBitmap within VCL.Graphics. In the first screenshot, exception occurs at line:
Result := GDICheck(CreateCompatibleBitmap(ScreenDC, bmWidth, bmHeight))
In the function GDICheck() in the second screenshot, the variable Value is zero in the debugger, so in turn function GDIError is called. There, ErrorCode is zero as well, this leads to the call to OutOfResources.
Hope this helps to narrow it down further.
* Edit 2016/07/19 *
Since nobody here seemed to have the issue, we gave it a different try:
A colleague of mine in the company did a fresh C++ Builder 10.1 Berlin install, in English (thought maybe the German IDE is the culprit),
and first thing after the install, recreated the StylesCrashTest App. Result is the same, it crashes at once after selecting a file and hit 'open' in the dialog.
I have uploaded the test project here
http://fboom.me/file/9904e22ddd22b/StylesCrashTest.zip
and our generated release exe here
http://fboom.me/file/368d0b62cc1a7/StylesCrashTest.exe
The exe is tested with many antivirus scanners on virustotal.com.
https://www.virustotal.com/de/file/e96f2e7eb80c162c2e5998decc15f26615c9fc76efec73379dd2e2140e4eba08/analysis/1468952442/
It would be helpful if you guys could test the exe and the test project and this could lead to separate the issue to either computer related or related to the installed IDE/generated exe. This of course only if someone can reproduce the issue.
With this exe, the app crashes here on two Windows 7 x64 Enterprise computers in a commercial environment.
It does not, however, crash on my private computer with Windows 8.1 x64 Prof.
Right now I am at a dead end, nobody outside the town of Munich seems to be able to reproduce the issue, but we have it definitely on two different computers.
The issue is also filed with Embarcadero (login required):
https://quality.embarcadero.com/browse/RSP-15019
Sadly, at the moment, this is a shop stopper for us for using VCL styles.
I found a fix to get rid of the crash. After some more debugging, it was discovered that the exception occurs every time TBitmap::SetSize is called with a negative parameter on the VCL styled TComboBox.
Please see the call stack in the attached screenshot:
TComboBoxStyleHook::ListBoxWndProc
TComboBoxStyleHook::DrawListBoxVertScroll
TBitmap::SetHeight
TBitmap::SetSize
After editing SetSize() in Vcl.Graphics.pas to exit on negative numbers the exceptions seems to be gone.
This is no fix for the cause of the exception, because why the parameter is set to -1 in DrawListBoxVertScroll is still unknown (bug?, could also be the result of a lot more sub calls within this routine), but at least it is
a fix to prevent the exception. Tested on all our machines where the exception took place with positive results.
Would love to hear the opinion of some real VCL experts like Remy Lebeau or even the VCL developers about it, though.
Again, I realize that not everybody can even reproduce the exception, but with the test project linked above, the exception is inevitable on our systems.
The TWebBrowser component in Delphi XE2 seems to be seriously buggy. Is there some sort of code I have to run in order to instantiate it in some special way?
Create new Delphi project
Drop a TWebBrowser component onto the form.
In Form1.FormCreate() call WebBrowser1.GoHome (to google).
If I compile this 32-bit and go to some specific webpages I get error messages.
google (ncbi nucleotide blast) and click the first link.
In addition to these javascript errors if I click a link which usually opens in a new window, it opens in IE (a separate application).
The 64-bit version seems even more broken. By going to that same site (ncbi nucleotide blast) I get the entire program crashing due to a 'divide_by_zero' error.
Regarding the floating point exceptions, TWebBrowser expects to operate with floating point exceptions masked. It looks like you are using Delphi default floating point settings and have exceptions unmasked. I suspect that if you mask exceptions then your problems will disappear.
Do that like so:
SetExceptionMask(exAllArithmeticExceptions);
And as others have said, you silence the Javascript popups by setting Silent to True.
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.
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.