View Issue Details

IDProjectCategoryView StatusLast Update
0035414LazarusIDEpublic2020-06-06 03:43
Reporterchronos Assigned ToMartin Friebe  
Status resolvedResolutionunable to reproduce 
PlatformWindows 64-bitOSWindows 
Product Version2.0 
Summary0035414: Error dialog always shown on exit of debugged application
DescriptionIf any project is run from Lazarus IDE then an exception is raised after executed application is exited/closed. It started to happen suddenly and it is probably related to some OS updates, MacAfee or Crowdstrike Falcon protection. It happens only if an application is executed from IDE. Not if it is executed directly as compiled executable. So it is somewhat related to debugger.

Tested also with IDE 1.8.4 with same behavior.
Tested on 3 company computers with all running Windows 7 64-bit with the same result.

As workaround I found out that in Compatibility tab of Lazarus shortcut I can select "Compatibility Mode" with any version of Windows and then the problem with exception disappears.
Steps To ReproduceStart Lazarus IDE.
Create new project.
Execute project.
Close Form1.
Error dialog with exception will appear.
After closing error message Assembler window would appear with location inside RPCRT4!Ndr64AsyncClientCall function.
TagsNo tags attached.
Fixed in Revision
Attached Files



2019-04-18 14:00


Error.png (6,403 bytes)   
Error.png (6,403 bytes)   


2019-04-18 14:00


Assembler.png (33,133 bytes)   
Assembler.png (33,133 bytes)   

Martin Friebe

2019-04-18 17:08

manager   ~0115654

I can not reproduce this. (Though I have win 10)

I tested the 32 and 64bit 2.0.2 install (2.0.0 should be the same). Though my test app consists only of a simple form, with an open dialog on it (and executed, on button).

This issue may only arise with specific components.

If your app uses file dialogs (open/save/select dir/ maybe printer) then it may also depend on 3rd party software installed. Those dialogs load libraries from 3rd party software into your app (shell handler for file context menu, etc).

Please see if it happens with a simple form (no file dialog) for you?

Also in case you are cross compiling (between 32 ad 64 bit) make sure that your debugger config has the path like this
This ensures that the gdb according to the bitness of your target app is chosen. Using a gdb with a bitness different than the debugged app will definitely cause trouble.

You may also wish to try the following:

Check DisableLoadSymbolsForLibraries

2) Use an alternate version of GDB
For 64 bit
For 32 bit


2019-04-23 11:26

reporter   ~0115747

Thanks for the tips.

The exception is always thrown even with default blank one form project. Without any OpenDialog or SaveDialog components. Also with "Simple program" console application.
I use 64-bit Lazarus with 32-bit cross-compilation. Gdb path is set correctly and binaries look ok.
Tried alternative GDB 8.2 with same results.
Tried to delete(rename) Lazarus configuration directory but I have same problem also with default settings.
Tried Lazarus 2.0.2 64-bit without 32-bit package installed with default settings and same error always appears. So the problem should not be Lazarus configuration or installed packaged dependent.

Unfortunatelly I can't uninstall/disable/change system applications like antivirus and other protection tools as it is company laptop. I don't even know how to get some log from Mcafee.
I don't have any windows 10 remote machine available to test if Lazarus/GDB is working under Win10. But if it would, then it would still doesn't solve the problem with Windows 7.
So it is probably similar problem like with other antiviruses

Martin Friebe

2019-04-23 13:21

manager   ~0115749

Ok, I can get a similar issue (not yet sure if anything can be done about it)....

If I press "stop" in a 64bit IDE, with a running/debugged 32bit app, then I get such an error.
It even happens when changing breakpoints while this app runs.

If however, I close the same app, using the normal windows red cross close button, then the app exits with no issue at all.

Martin Friebe

2019-04-30 19:48

manager   ~0115931

Can you please test with svn trunk revision 61090 or up?

You need to install LazGDeBugControl.exe.
This can be found in
Or build from sources under components\lazdebuggergdbmi\apps\lazgdebugcontrol

To cross-debug a 32 bit app, you need a 32bit build of LazGDeBugControl.exe.
LazGDeBugControl.exe must be in the same folder as your 32bit gdb exe.

You can use the task monitor to verify the setup. Once your app is running in the debugger, there should be a LazGDeBugControl.exe shown as running in the task monitor. (And it should keep running, at least until you stop debugging)

Does the issue still exist, once you have the above setup?

To cross-debug a 64bit app (from a 32bit IDE, you need a 64bit build of LazGDeBugControl.exe.And must have it together with the 64bit gdb.


2019-05-06 14:27

reporter   ~0116043

Thanks for another reply. Mantis was not sending me notification emails. I activated those options in my profile so I will see if it works.

From your description I don't understand how I am supposed to use that LazGDeBugControl.exe? Just to put in to the same directory as gdb.exe? Something like "C:\lazarus\mingw\x86_64-win64\bin\ ? How lazarus will see that it should use that file? Is it usable only for cross-debug or also for normal non-cross-debug?

And you write about "cross-debug" but I just use 64-bit lazarus with 64-bit gdb. So where is that "cross-debug" thing used? Usually I do only cross-compilation from 64-bit to 32-bit to have both 64 and 32-bit executables in one innosetup installer. But debugger should run simply in the same bit width as the application.

Martin Friebe

2019-05-06 15:56

manager   ~0116046

Last edited: 2019-05-06 15:56

View 2 revisions

Maybe there is a missunderstanding. In 0035414:0115747 you wrote:
>> I use 64-bit Lazarus with 32-bit cross-compilation. Gdb path is set correctly and binaries look ok.

So I assumed you debug 32bit apps from within 64bit apps.
In that case, you need LazGDeBugControl.exe
The IDE looks for a file of that name in the GDB folder, and uses it if present (but only for cross debugging).

As for debugging 64bit apps from 64bit IDE.
I can not reproduce this on my PC.

The installed cross compiler should not matter. But please verify that the correct 64bit GDB is actually used (rename the 32bit gdb / or check with the task manager, if win7 task mgr shows the bitness)

Please test the following:
Tools > Options > Debugger: In the property grid set "DisableLoadSymbolsForLibraries" to true.

If that helps, then you the problem will be down to some library that conflicts with gdb. If you go through the GDB output, you will see that some libraries are always loaded when you run your app.

(If that helps, and if possible for you, then test this with GDB 8.2 too, thanks)

 If it does not help, then please generate a logfile:
and reproduce the problem (ideally with a minimum empty form app)

Martin Friebe

2020-06-06 03:43

manager   ~0123248

no further feedback received / unable to reproduce

If the issue still occurs, even when using LazGDeBugControl then please re-open.

IF LazGDeBugControl fixes the issue, this should be part of 2.2 and the issue would be resolved.

Otherwise please add feedback (and reopen) if available.

Issue History

Date Modified Username Field Change
2019-04-18 14:00 chronos New Issue
2019-04-18 14:00 chronos File Added: Error.png
2019-04-18 14:00 chronos File Added: Assembler.png
2019-04-18 15:10 Martin Friebe Assigned To => Martin Friebe
2019-04-18 15:10 Martin Friebe Status new => assigned
2019-04-18 17:08 Martin Friebe LazTarget => -
2019-04-18 17:08 Martin Friebe Note Added: 0115654
2019-04-18 17:08 Martin Friebe Status assigned => feedback
2019-04-23 11:26 chronos Note Added: 0115747
2019-04-23 11:26 chronos Status feedback => assigned
2019-04-23 13:21 Martin Friebe Note Added: 0115749
2019-04-30 19:48 Martin Friebe Status assigned => feedback
2019-04-30 19:48 Martin Friebe Note Added: 0115931
2019-05-06 14:27 chronos Note Added: 0116043
2019-05-06 14:27 chronos Status feedback => assigned
2019-05-06 15:56 Martin Friebe Status assigned => feedback
2019-05-06 15:56 Martin Friebe Note Added: 0116046
2019-05-06 15:56 Martin Friebe Note Edited: 0116046 View Revisions
2020-06-06 03:43 Martin Friebe Status feedback => resolved
2020-06-06 03:43 Martin Friebe Resolution open => unable to reproduce
2020-06-06 03:43 Martin Friebe Note Added: 0123248