I have a project developed in delphi, that intends to install some components. These components are nothing but just inherited children of Firedac, and some other.
When I open the project in Delphi XE6, it opens fine. But, when I try to install the .bpl project by right clicking on project and selecting install option, the IDE crashes everytime.
The target platform is 32 bit.
Each time, when XE6 crashes and gets shut down, there is a error in event log. The screenshots for event logs are attached.
Also, I have tried with allowing the bds.exe app in firewall profiles.
It used to crash earlier also, but after trying for some time, it used to work. Now it does not. I have also tried with old code base for .bpl project but that does not help.
Any help on this is really appreciated.
The likely explanation is that there is a defect in the initialization or registration code of the bpl. The error code 0xC0000005 is the NTSTATUS code for an access violation.
Whilst the error is raised from the Delphi runtime module rtl200.bpl it is your package that is the likely culprit. Probably it has called the runtime library passing invalid data.
You will need to debug your package to solve this. Start by stripping code out of it progressively until the error disappears at that point you know that the error is caused by the code you just removed. Refine the process until you have a strong lead, and then follow that lead.
Related
I'm updating an existing GLScene app to Delphi 10.3. I've got latest GLScene installed (from https://sourceforge.net/projects/glscene/) but TGLSceneViewer component is causing an error.
Even on a new project when I drop a TGLSceneViewer on a form I get Loadlibrary failed with error 126;
Pressing 'OK' and Delphi crashes out back to Windows desktop; it kills the IDE without any dialog or error. (As you can see, already placed TGLScene component GLScene1 doesn't error.)
I've used ProcessMonitor to try to find the problem (as directed by responses to LoadLibrary 126 errors);
So the error appears to be missing 'd.DLL'. That must be an invalid dll name so is there some installation issue?
Has anyone come across this problem? Thanks!
UPDATE:
So I've dug through the GLScene source to try to find references that might be related to 'd.DLL'.
In the screenshot below ('Messages' section) there are references to constructed dll names (CUDARTDLLNAMES[I] + '.dll' and CUFFTDLLNAMES[I] + '.dll') in CUDA_Runtime.pas and CUDA.FourierTransform.pas. It is possible these could create the name 'd.DLL' except that 'DLL' is not capitalised in the code?! I'm just scratching around here for a solution.
Also interesting that file 'Imports.Newton.pas' refers to four dll files that are not included in the install externals folder;
newton32d.dll, newton32s.dll, newton64d.dll and newton64s.dll
Again, I don't know if that's relevant as far as TGLSceneViewer successfully loading in Design mode.
Thanks again for your help.
It seems you haven't install GLScene properly on your system.
Based on the fact that you seem to be missing required dynamic library I guessing you have skipped 2. step in Instalation instructions for GLSCeene
You should always read the accompanying documentation. This will be especially important when you will be distributing your application to end users since documentation has detailed information about dependencies that needs to be shipped with your application for it to function properly.
So after a lot of trying to identify what 'd.DLL' was I narrowed it down to 'PhysXwrap32.dll' because by renaming that to 'd.dll' I then got a different (access violation) error, i.e. things had moved on a bit! In fact the 'earth.exe' demo program ran to some degree (no texture) after placing d.dll in the exe folder and ignoring the access violation error on startup.
Anyway, it was clearly messed up so I tried some other GLScene installs. All the versions installed fully in Delphi 10.3 IDE with packages registered and components available but still I was getting Loadlibrary error 126 when dropping TGLSceneViewer on a form.
Eventually I found and installed 'GLScene_v1.8_for_RX_10.3_Rio.7z' and finally didn't get that 126 error! I got another error instead, Loadlibrary error 87. This is normally related to graphics driver issues. So following various posts about that I disabled the onboard Intel 630 graphics and made sure the AMD drivers were up to date.
After a restart finally I can use TGLSceneViewer!
So I've got GLScene v1.8 installed and working on Delphi 10.3. Maybe the graphics card conflict is also related to the problems with GLScene v2 but it was showing a different error (Loadlibrary 126 instead of 87). I'll try it sometime when I've nothing else to do, haha.
Thanks for your help and interest.
I'm trying to move a project that was done in a previous version of C++Builder to 10.1 Berlin (I am using the trial version of C++Builder).
The project was converted and compiled succefully with minimal efforts. Then I got the well-known linker LME288 problem, but it was resolved by starting C++Builder as an administrator.
But now, when I start the application, I get a message box saying "Abnormal program termination" at the very beginning - even before the main window appears on screen.
The situation is the same for debug and release versions, under IDE and as standalone. When I start the program inside the IDE, and set a breakpoint at the very first statement, the error message appears before this statement.
I have Windows 10 Pro, 64-bit. C++Builer 10.1 Berlin trial. It shows the only accessible platform is Win32, but I don't know if this is a reason for an error. The program worked fine for previous versions.
Could anybody advise me what to do? Is there a systematic way of investigating the problem?
I have tried all recommendations I could found - use debugger, show us the code, try reinstalling software or Windows, upgrade to latest updates, etc. But I have never seen a systematic approach.
Here are a couple of things I had to do to get my project working.
1) Start a new project. For some reason old projects can get corrupted and produce strange errors. I recommend starting a new project and adding your files to it.
2) Use an old version of borlndmm.dll The version provided with C++ Builder 10 produced crashes for me that made no sense. I overwrote the provided copy of borlndmm.dll with a copy from XE6 or XE8. That solved my problem.
Hopefully one of these will help you.
From time to time, when I load a project into the XE6 IDE, the following error occurs
This error results in the TZConnection component being removed from the Datamodule for some inexplicable reason. Note that the project has been loading without issue for ages and just out of the blue, this occurs.
Has anyone seen this before and know of a way of stopping it from occuring ?
It also occurs with other components, not always the TZConnection component but mostly ZConnection.
Like I said before, this appears randomly. I could close project A, open project B then close it and return to Project A and bang!, the error occurs.
Any clues ? (note that this also used to occur in Delphi 2007)
The Zeos libraries are themselves causing this problem.
To see why, and to fix it, use Delphi to launch a second instance of Delphi, and debug the issue directly.
I wrote a blog post showing exact steps here.
The key is to set the executable that will be run for your zeos package, be sure to build them in debug configuration, and then click the Run button on the Delphi IDE toolbar. A second delphi instance will start. Open the affected form but be sure to be using the IDE instance that is Being debugged as opposed to the one which is currently doing the debugging, when the exception occurs that is causing your component to delete itself, you will be able to step into the package code and see the problem.
I suspect a DLL-hell path issue. (Multiple copies of Zeos or other core BPL/DLLs in your path.)
Actually, it doesn't sound that inexplicable - it's probably caused by an exception occurring as the DataModule (or some form with db-aware components connected to it via properties) is being loaded into the IDE (see below). Have you tried checking that wherever your ZEOS .BPL files are located is on your system Path? Likewise any .BPLs they depend upon - see the "requires" clause in the .DPK file(s) for Zeos.
This sort of problem arises fairly frequently with flaky DB components, maybe more so than other types of component because db components more frequently involve linkages between datamodules and forms, e.g. when db-aware components on the forms are connected to others on the datamodule.
So, sometimes, whether this sort of problem shows up or not depends on the order in which the IDE will re-open them - try closing the project with only the dm open and then re-opening it. A bit of experimenting with which datamodules and forms are open in the IDE and in which order may help you pin down the problem. If/when you have a reproducible sequence of steps to provoke the problem, report it to the authors.
A fairly reliable way to determine whether the problem is being caused by an exception as a project loads is to run one instance of the IDE inside another. As long as the first ("outer") instance of the IDE has the debugger set to "Break on Language exceptions" it should be able to take you straight to the source of the exception (assuming it occurs, of course) when the project is loaded by the second instance. It may take a few goes to "catch it in the act" of course, but it is hugely satisfying when you manage to. Good luck!
Unlike MartynA I doubt this would be caused by an exception.
I would more likely expect such issues to be caused by windows path environment variable being too long.
Unfortunately still many component vendors and even some programs modify "windows path environment variable` to make their own files accessible by other programs.
And when windows path environment variable fails to provide sufficient information windows will try to find the files in default system directory which is C:\Windows\System32
So I would strongly advise checking the windows path environment variable to check its length.
The easiest way to do this is by simply starting the command prompt and typing in path directive or perhaps path >> D:\path.log to export the path environment variable information into a file for easier reading in case if it is long.
EDIT: BTW I just checked my path environment variable and I see that I will have to do some cleaning because it contains entries for both Delphi XE8 and Delphi XE 10 Seattle file locations even thou I have removed Delphi XE8 from my computer. Not to mention some entries from some programs that I have removed quite some time ago.
With XE8 update 1, Win 7 64 bit and a single component added to an otherwise empty folder I get:
error: [dcc32 Fatal Error] F2039 could not create output file .\Win32\Debug\MountTest.
The test will compile and run fine the first time but XE8 has to be shut down and restarted to compile again. The component is a gauge from Mitov Software.
The component vendor say's that this is a known bug with no fix. If so its a showstopper and project end'r for me. Is it really the end of the line for Delphi?
I hope some one can pull this rabbit out of a hat somehow.
This is what I have done to isolate the problem.
Started with a failing application (will not compile a 2ed time)
Remove all external units used
Remove al references to those units
Remove all references in the 'Uses' clause
Comment code until it compiles
It should compile every time you hit run (no problem).Now add a blank form to the project. Don't do anything to the form just add it. Add it to your uses clause.
Its should compile every time you hit Run.
Now open the blank form and simply touch it so that it needs to be recompiled.
When you run the application its back to failing when you run it a second time.
Notice that happens when you simply add a form and 'touch' it. No code needed.
This problem is not something wrong with my code - it can't be. Its a bug in the UI - must be.
Coincidentally, I just fought with this issue yesterday testing some components I ported to XE8. The output file in my case is the project executable.
After spending several hours trying to figure out what was going on (including efforts to reconfigure my AV software, disabling it entirely, moving the project to a different location, etc.), I was able to solve the problem by disabling Castalia. If I run the IDE without Castalia, the problem does not occur. If I enable Castalia again, it starts happening again.
You can find instructions for disabling/enabling Castalia in How can I disable Castalia in XE8?
I'm removing the above content because the issue has reappeared (with Castalia disabled). Further investigation shows a couple of things:
The problem seems to be related to any sort of exception being raised in the debugger (even those that are handled in the code). Clicking either Break or Continue in the debugger exception dialog works as always. However, the next attempt to compile or build the application fails with the F2039 error. Deleting the executable in Windows Explorer allows compilation and running once, and then the error recurs.
Restarting the IDE fixes the issue, until the next debugger exception occurs.
Neither taskkill or a batch file with del worked in either a pre- or post-build event.
There is an open QC entry for it at Embarcadero which indicates that it was reported in XE7, XE7.1, and XE8, and is currently an open internal ticket. I can't find a way to add the information in the two points above to that open ticket in the new JIRA-based Quality Portal. Perhaps someone who has access and can do so will on my behalf (or at least add a link to this post).
It's not linked to a specific project. The original answer (as mentioned above) was related to a test app while porting some components to XE8 from an earlier version. When the problem reappeared for me, it was in a brand new project, totally unrelated, that does not use any non-standard components.
(I previously had access to EMBT QC, and had a few open tickets. The accounts appear to have not migrated to the new QP, and I can't locate any tickets there under my account.)
Found It.
I decided to start from scratch on my development system and uncovered the problem.
I installed Windows 10 on a virgin disk
Installed XE8 update 1
Installed MITIOV Instruments for XE 8 and tested them. All working find
Installed AsyncPro - Still working
Installed the JEDI Jcl - Fails
Remove JEDI Jcl - now works
Trash JEDI completly - Everything works fine
Something in the JEDI Jcl version 3.48 is causing the problem. I can code around the JEDI components I was using without to much trouble but its a shame.
How about automatically kill your "hang-up" application before build?
I also had this problem on Win 7 Pro 64 bit with XE8.
Removing JCL fixed the problem. If I was a betting man, I would look closer at the JCL Debug IDE extension.
Guy's..
There is no reason to upgrade to Delphi 10.1, because all previous versions are equipped with an older version of the Android SDK.
Now, how to solve this annoying issue:
Just find the map where the Android SDK is located.
See: Tools/Options/Delphi Options/SDK Manager/Android Location
Now run the ..\sdk\tools\android.bat as Admin
This will show the Andoid SDK Manager.
Next is to update to the newest Android SDK and SDK Tools.
If all completed, you don't have to upgrade to Delphi 10.1 or whatever "advised".
Restart Delphi and problem:= solved!
btw:
It took some effort to find out what's happening here, because the Eclipse compiler suffered the same issue as Delphi. Finally all was related to bugs in earlier versions of the Android SDK causing adb.exe to keep a filehandle held hostage.
I have a frame that never had any problems before. Now when I am in the Delphi 6 IDE and I try to draw an instance of it on a Form in design mode, the IDE exits immediately without any crash errors, dialog boxes, or Watson style "please report this error" message boxes. I am running on Windows XP and I have never seen the Delphi IDE do this before. The frame doesn't even have any of my custom components on it, just some of the stock Delphi VCL components and a few third party components from a library that I have used without trouble for years. I tried several other frames resident in my project and I can still create those at design time without error.
Note, I did try a complete clean of all project DCUs and rebuilt several Delphi packages for my custom VCL components just in case but those efforts changed nothing.
Does anyone have any tips for diagnosing and fixing this problem?
It is possible to configure Delphi to debug itself. You launch a second copy of Delphi, and you might be able to see where in your code, and the only reasonable thing I can assume is that suddenly there is a problem with the code of the third party library components. To locate the source and line number of that crash, the Delphi debugger itself may be of some use.
Simply launch the third party component with Delphi.exe as the host executable (for Delphi 6 and 7), or bds.exe (for more recent Delphi versions). (In the IDE using Run Parameters, in the Host Application, put delphi.exe or bds.exe)
Then once you've located the source of the exception and fixed the code and recompiled the component packages containing that code, your problem may be solved.
Related answer by me
(Note that the madExcept idea is equivalent in that it might also give you a stack traceback to help you find what code is crashing, but in case it doesn't this technique is also valuable to know about.)