My app dies in Server 2019

[Berocoder 14]

I have a problem that needs to be solved.

I have an application written in Delphi 10.4. It is about 10 years old. It transform data from one database to another unsing Unidac drivers.
Runs on a Windows 2008 R2 Server. As it is old it needs to be replaced by a new virtual server with Windows server 2019.

Unfortunately my application don't works well. It runs for a while and just quit. Not an exception no sign of error at all before it dies.

At the same time we setup more strict permissions in Windows. Thought that this was the reason.
When I look in eventlog I see this:
 

Faulting application name: DatapumpOCL.exe, version: 2022.10.200.3483, time stamp: 0x6358d093
Faulting module name: KERNELBASE.dll, version: 10.0.17763.3532, time stamp: 0x95b80d84
Exception code: 0x0eedfade
Fault offset: 0x00125232
Faulting process id: 0x237c
Faulting application start time: 0x01d8f9bcde0671f6
Faulting application path: C:\Ahola\AholaDaily\DatapumpOCL.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: 404588fe-4a1d-45a2-8c13-42a4b0136ced
Faulting package full name:
Faulting package-relative application ID:

 

This is a 32-bit application. Windows Defender is running as antivirus. But Defender seems only have information as logs. No errors.
I have tried to turn off everything in Exploit Protection just for this DatapumpOCL.exe. I have tried to turn on checks for Range, Overflow and IO in Delphi compiler settings but still the same.

So out of ideas now 
 

 

Edited November 18, 2022 by Berocoder

[FabDev 8]

Do you try to compile it with trace software like the very good MadExcept ?

[Der schöne Günther 316]

See

Writing Dynamically Loaded Libraries - RAD Studio (embarcadero.com)

 

Quote (emphasis by me):

Quote

 

(...) the exception can be handled as an operating-system exception with the exception code $0EEDFADE. The first entry in the ExceptionInformation array of the operating-system exception record contains the exception address, and the second entry contains a reference to the Delphi exception object.

 

Generally, you should not let exceptions escape from your library.

 

 

[Lars Fosdal 1792]

46 minutes ago, FabDev said:

Do you try to compile it with trace software like the very good MadExcept ?

This is essential to catch issues in runtime.

 

Running an executable without it is like making a train travel blindfolded. 

You might get where you are going, but if something unpleasant happens on the way, you have no idea of what actually happened.

 

EurekaLog or MadExcept are the best known solutions for capturing exceptions and stack traces.