debugging fails on a win10 machine

[CapelliC]

Seems I'm rather unlucky with debuggers 

On a specific Windows 10 machine the executable cannot be debugged, when I add a specific feature.
I means, I have $IFDEFed the sections of the code that inhibit the correct startup, and reduced the code to a small subset, so I can easily try with various options available in the IDE, but I've been unable to fix the problem.

The very same project can be debugged without problems on at least 3 different win10 machines, but where I need it most it refuses to start, displaying instead the message allegated.

I've tried to enable the system log - as suggested by Martin_fr in https://forum.lazarus.freepascal.org/index.php/topic,50852.msg372328.html#msg372328 - but haven't found anything notable. Of course, there is the same info displayed by the error box:
...
  << TCmdLineDebugger.ReadLn "=thread-exited,id="2",group-id="i1""
  << TCmdLineDebugger.ReadLn "=thread-group-exited,id="i1""
  << TCmdLineDebugger.ReadLn "^error,msg="During startup program exited with code 0xc0000135.""
...

The application in release mode starts without problems (if launched from the IDE or the Windows shell), while in debug mode Windows doesn't run it. Seems the executable format is wrong for some reasons. The feature I switch on/off is just a recompilation of an old component (FlexCel), where - to be true - I don't know how to regenerate the EmptySheet.res that gets embedded during the build process... but the old one works - as I said - on every other machine I've tried... so should not be the problem...

I understand this is a poor question, but... is there any chance to get the debugger working on that machine ? It's a lot that I'm unable to progress on this problem.

TIA for any help...
Carlo

[440bx]

On a specific Windows 10 machine the executable cannot be debugged, when I add a specific feature.

The reason the program does not start is because the Windows loader is unable to find one (or more) of the DLLs the program depends on.

The "Dependency Walker" utility, which is available at https://www.dependencywalker.com/ may allow you to determine which DLL is missing.

HTH.

[CapelliC]

Thanks for the hint, but - also admitted it would be pertinent (iirc, windows display a specific message when a dll cannot be found), it doesn't explain why the application starts in release mode, or in debug mode when I exclude the misbehaving sources.
As I briefly explained, the culprit component is not a dll, but a set of units (.pas) and includes (.inc) that I have added to the project (just the .pas).
Also, on every other machine I haven't installed anything specific for my application beyond Lazarus itself (well, of course it depends on the machine, but these are very diverse and one is brandnew, almost nothing installed there)

[Martin_fr]

You are running
- on a 64 bit machine
- a 64 bit Lazarus
- compiling your project for 64 bit
?

Common problem solvers that are worth trying

1)
https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#On_Windows_Open.2FSave.2FFile_or_System_Dialog_cause_gdb_to_crash
Set DisableLoadSymbolsForLibraries

2)
Use an alternative GDB. For 64 bit targets: https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Alternative%20GDB/
If your environment (eg username) has not ASCII chars (none latin, or umlauts....) then you must use 7.3.5
If you are latin chars only, try .8.2

3)
Try FpDebug
   Menu: Package > Install Packages
Install the package:   LazDebuggerFp
(No download required, the installer already contained this)
Then
Tools > Options > Debugger
Change the debugger type to "FpDebug Internal dwarf debugger (beta)"

You can choose Dwarf-3 if asked. But if you ever go back to gdb, then (when you go back) it needs to be "dwarf with sets".

[440bx]

... the culprit component is not a dll, but a set of units (.pas) and includes (.inc) that I have added to the project (just the .pas).

It is possible that the additional units depend on some dll.

In addition to the suggestions from Martin_fr (which are all good), if you have Visual Studio installed, you can try debugging the app in Visual Studio.  For that you'd need the cv2pdb utility.  If Visual Studio can load and debug the program then it would point to GDB as the cause of the failure.

If you'd like to try the above, you'll find more information on using the Visual Studio debugger in this thread https://forum.lazarus.freepascal.org/index.php/topic,42000.msg295128.html#msg295128

HTH.

[Martin_fr]

In addition to the suggestions from Martin_fr (which are all good), if you have Visual Studio installed, you can try debugging the app in Visual Studio.  For that you'd need the cv2pdb utility.  If Visual Studio can load and debug the program then it would point to GDB as the cause of the failure.

If GDB is the point of failure, then FpDebug should also work. FpDebug is 100% GDB free.

[440bx]

If GDB is the point of failure, then FpDebug should also work. FpDebug is 100% GDB free.

I understand that.  I suggested the Visual Studio debugger in _addition_ to your suggestion of FpDebug in a previous post.  I don't have any experience with FpDebug therefore I cannot help the OP with it but, I could help the OP if he chose the VS debugger, plus that would expand his options/knowledge which is always a good thing.