I'm writing a FireMonkey HD application on my Windows 32 bits machine, and deploying (remote debugging) it on my MacBook running Snow Leopard. I'm running the Delphi XE2 Trial.
Everything is working fine, except for one thing: every other run I hit the following error when I press F9:
Fatal error starting debugging kernel: "Invalid debugger request".
Please save your work and restart Delphi XE2.
Restarting XE2 and running again cures this problem... for exactly one run, then I hit the same error again. Whether I stop the debugging run through CTRL-F2, or gracefully close the application on the Mac, makes no difference. It happens on every project (including new, empty ones with only a single FireMonkey form).The PAServer terminal has no information, it's still on "listen".
Anyone has any tips on how to avoid this issue?
Installing the full version of Delphi XE2 (including update 1) seems to have fully solved my problem.
I've checked the Bug Fix list for any references, but no such luck. Oh well, problem is gone anyway.
[EDIT] And now, the very next day, the problem re-appears.
Delphi 10 gives a similar adventure (Win32 --> Win32 target). It's "business as usual" for the remote debugger.
Related
Update: as noted by some, this is a problem brought about by NOD32. An issue item for this in their system is:
https://forum.eset.com/topic/16237-probleme-debug-delphi-with-eset-11249/
Delphi 10.2.1 and 10.2.3 hang when starting (with debugging) any 32 bit application on Windows 10/64. This started after the computer was rebooted for the weekend like it is every weekend.
Debugging a 64 bit project compiles & runs ok.
Debugging a 32 bit project compiles but hangs before/slightly after the project even starts running ("end task" on Delphi is the only option now). If I run without the debugger, the project runs ok. Delphi "stops responding".
I've seen this single form "do nothing" test application I have used to investigate this freeze after loading Kernel32 or Comdlg32.
Hearing how similar this is to the problems with Delphi 10.2 and Windows 10's Creator update, I migrated to Delphi 10.2.3. Same problem as before.
I restored to a backup of the Windows partition. After I did that, it worked until I rebooted and then it broke again.
I went to an earlier backup of the Windows partition & got the same result.
This is so strange...any ideas?
I Thought it might relate to Nod32 as I had the same issue happen after a nod 32 update.
I have added the BDS.exe directory to be excluded from real time file system protection.
Seems to be fine now.
I have seen this kind of behavior with F-Secure antivirus and Windows 10 1803 (April 2018 Update).
This is similar to the last comments on this post : http://blog.marcocantu.com/blog/2017-june-delphi-packages-creators-update.html.
The only workaround I've found was to define the affinity of the BDS.exe process.
You can do this by right clicking the bds.exe process in the Details tab of the Task Manager and Define affinity but it will only define it for the current run.
You can define affinity definitively by running BDS through the command line.
Here is my shortcut :
C:\Windows\System32\cmd.exe /C START /affinity 1 bds.exe
ESET is deploying 11.2.63.0 release of it's antivirus and the problem of freezing Delphi for Win32 debugging is now solved.
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.
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.
At seemingly random intervals, I encounter the following error when attempting to debug programs in Delphi 7:
The only way get rid of this error is to close and reopen Delphi and even when I do this I normally see the error again fairly quickly. Restarting my computer can sometimes be useful in stopping the problem from appearing for a while.
To be clear, I am able to compile my project, it's only when I attempt to debug that I have this problem. This seems to be the DLL responsible for debugging, which makes sense.
Delphi is running within a Windows XP SP3 Environment.
insert delphi installer cd, run install and chose repair.
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.