Error loading database on Lyrix.exe (Delphi 7 legacy application) on Windows 10

Question

There is this application called Lyrix written in Delphi 7 (it seems) for which I only have the executable folder (and installer which doesn\'t run anymore). I can\'t get it to

Answer 1

Short version

Change the Locale to use "." as a decimal seperator instead of a ",". The application is coded to use the Locale/Culture of the machine it is running on, which could change over time.

So, check the Control Panel's Region -> Formats -> Additional Settings -> Decimal Symbol value.

And if your database has stored the values in one region and tries to load it in another region, it will fail as above.

---

Full version

Over a few days I managed to go down a rabbit hole to find the issue.

First, I tried the app on a clean slate VM machine. I ran ProcMon from SysInternals to monitor everything that is done. I monitored registry entries, disk access etc. Looking for something that was giving an error. No luck there.

I thought it would be a database driver issue, or that I was missing some ODBC connection or something, but nope, I tried turning on tracing for ODBC, but nothing was logged. I tried installing the 2010 Office System Driver as suggested in other places, but that didn't solve anything. I tried 32bit and 64bit Windows 10 versions, both had the issue.

Then, I went into the exe code and tried a few tools like the IDR (Interactive Delphi Reconstructor), to see what strings I could see. I was looking for the database connection information. The database was hardcoded to access an .mdb file using the connection string Provider=Microsoft.Jet.OLEDB.4.0;Jet OLEDB:Database Password=xxxxx;Persist Security Info=False;Data Source=

So I tried changing the string to use Microsoft.Jet.ACE.12.0 instead, and using tools like PE Explorer, Resource Tuner, DeDe, ResEdit, Resource Hacker etc. But still no luck in getting the recompiled/saved with new database connection strings version to work.

Then I decided I need to see what the reason for the error is, so I needed to debug this app somehow so that I could see the Exception's true reason. I was just getting a generic Exception 0x0EEDFADE. So I got hold of WinDbg to check what's happening. I dabbled with procdump too. But WinDbg got me the stack traces I needed, and using the techniques on https://marc.durdin.net/2012/08/locating-delphi-exceptions-in-a-live-session-or-dump-using-windbg/, I managed to find this in the one exception: "'2.2' is not a valid floating point"

That exception confused me, but I realised then that it was the format of the numbers on the system that was probably different, the "," vs "." issue for the locale/region of the machine. And indeed, Windows 10 decided to change the default locale for Decimal point seperator to a comma instead of a full-stop for South Africa. There's no doubt many other legacy or older applications that aren't coded right but used to work fine before Windows 10 will stop working because of this issue.