I have a Delphi 2007 application protected by MadExcept. It's running without any problem on Windows 10 systems. Only one customer who was using the application successfully started getting access violation this week. The MadExcept dump shows this:
main thread ($1e24):
0040477f +00f test.exe System 90 +0 @_CLenToPasStr
00404769 +005 test.exe System 90 +0 @_CToPasStr
004b68e9 +031 test.exe Forms 2947 +3 TCustomForm.DoCreate
004b64c8 +124 test.exe Forms 2856 +13 TCustomForm.Create
00a4d832 +016 test.exe simpmain 912 +1 TMainWin.Create
004bfff6 +06e test.exe Forms 8280 +7 TApplication.CreateForm
76598482 +022 KERNEL32.DLL BaseThreadInitThunk
This is a Windows 10 Home system on the latest update. I have tried to reproduce the problem with no luck. Also, no other customer yet reported this. What can this be?
I've no idea, haven't seen this before. Could be one component on your TMainWin form acting up when being "created". Or could be a corrupted EXE file, but if you have the "check whether exe file is corrupt" option in madExcept activated, madExcept should report the corruption, so that's probably not it. I suppose you could compile with debug DCUs, then on your PC check where TMainWin.Create calls _CToPasStr exactly, and for which purpose. Of course you could also try to check the madExcept disassembly to figure out why _CToPasStr crashes.
Thanks for the tips. I found out that Windows Defender on Win 10 has a new Ransomware switch that when turned on disables all folder access to all the apps. As a result SHGetSpecialFolderLocation type calls start failing. The problem was I have never encountered a failure of this function and its wrapper was coded to return an empty string on error. This empty string was being passed to AnsiLastChar for checking which can't handle an empty string and gives access violation. This is a legacy D2007 app.