After installing madExcept 5.1.3, Alexandria 11.3 does not start.

[tam]

I installed madExcept 5.1.3 using madCollection 2.8.12.0 installer with Delphi Alexandria 11.3.
Now the IDE stops in the startup process while loading the package 'madBasic_.bpl'.
After some seconds the IDE terminates without any error message.

[madshi]

That is bad. Can you try giving your madCollection root installation folder (and all sub folders) read & execute reads for Everyone (or at least for the user you're running the IDE under)? I wonder if that might be the cause of the problem. It could also be something else, of course. FWIW, for me, 11.3 starts up fine.

[tam]

The access rights of the installation folder (C:\DEV\prj\Trunk\thirdparty\madCollection50) and all its subdirectories are ok. The prevoius version of madCollection was installed in the same folder.

[madshi]

You could try a cleanup as follows:

1) Uninstall madCollection.
2) Search harddisk and registry for mad* and delete all remains of madCollection (if any).
3) Reinstall madCollection.
4) Double check NTFS rights once more.

That often helps, though the IDE not starting when trying to load madBasic_.bpl is something I've not seen reported before. So I'm not sure what kind of problem that could be.

Two more random ideas:

1) You could double check if maybe your anti-virus is throwing a spanner in the works by disabling the real-time protection temporarily (of course you can double check the madCollection files with www.virustotal.com first).

2) You could rename the madBasic_.bpl, after which the IDE should load, but obviously the IDE will complain about all the madCollection packages. Once the IDE is up, you could uncheck all the mad* packages and then re-check them one-by-one, starting with madBasic_.bpl, to see what happens then.

I wonder if maybe there's some package (either one of your own packages or a 3rd party one) that is relying on madBasic_.bpl which was compiled with a different version of madBasic? Or maybe, the IDE is still loading some old madBasic_.bpl file from a different file path?

Just some random suggestions. As you know, it's very hard to fix a problem if you can't reproduce it on your own dev PC.

[tam]

After uninstalling madCollection, cleaning the mad* registry keys and reinstalling madExcept, the problem ist still the same.
An exclusion of the madCollection installation folder in the anti-virus system is configured.

Here some further observations:
I can turn on the Design packages in the IDE step by step:
1. madBasic 1.2.8 --> ok
2. madDisAsm 2.2.6 --> ok
3. madHelp 1.1.1 --> ok
4. madExcept 5.1.3 --> after about 20 seconds the IDE terminates. The bds.exe process is killed.

[madshi]

Do you have any self-written BPLs loaded in the IDE? Or might there be any other 3rd party package loaded in the IDE which may internally use madExcept in any way?

The most likely problem is that the madExcept tries to catch exceptions within the Delphi IDE, and that is known to cause problems in Delphi 11, for unknown reasons. I've disabled this feature by default, but it might "accidently" be turned on again if there's some 3rd party IDE loaded which activates madExcept inside of the IDE.

[tam]

Everything works fine when madCollection is not installed. So no own or 3rd party package relies on madExcept.
The prevoius version of madCollection works for me, too. At least for 32 bit.
I will check if there are any correlations between madExcept and other packages. But not today ...

Thank you very much for your help and ideas.

[madshi]

Well, the packages don't really have to rely on madExcept, they just need to contain madExcept settings that tell madExcept to activate, I think. However, saying that the previous madExcept build doesn't have this issue confuses me, because I've barely changed anything, except for adding support for doing 64bit stuff properly.

If you can't find out what's going on, I guess we could try adding some logging to see what is going on inside of the madExcept package when it's being loaded in your IDE.

[tam]

Here a short update:
Fresh Delphi setup without any 3rd party experts or packages, only madCollection is installed: - No problems detected.
So it must be a local problem on my machine.

I'm extremely sorry for any inconvenience caused.

[madshi]

FWIW, it could still be madExcept's fault. But it does seem there's something that catalyzes the problem somehow...

[anouri]

I had Delphi 11.3 and 12 installed side by side. I feel that the problem could be that when installing madexcept when two different versions are together, a problem arises.
I thought it might be the cause of the problem.
I completely deleted version 11 and 12. I deleted all the folders related to Embarcadero. I installed Delphi 12 again. I installed the components and now there is no problem.

[madshi]

FWIW, I have all Delphi versions from Delphi 4 up to Delphi 12 installed on my dev PC, and it works just fine. So not really sure what the problem was exactly...

[masc]

Hi,

same for me with Delphi 11.3. After upgrading from madExcept 5.1.3 to madExcept 5.1.4.
Downgrading to madExcept 5.1.3 didn't solved the problem - it remained from then on. Before the update madExcept 5.1.3 was running fine.

I've

• tried a downgrade
• uninstall / install
• uninstall / install with disabled virus scanner
• restart of Windows
• registry cleanup
• checked file permissions / granted read, execute to everyone

The BDS.EXE start watched with ProcessMonitor doesn't look that bad - except it ends with launching C:\Windows\SysWOW64\WerFault.exe


Most operations were successful. Just <madCollectionHome>\madExcept\BDS22\win32\madExcept_.DE is reported as missing. But this file did also not exists in version 5.1.3.

In the Windows Eventlog I get the following log entry:

Code: Select all

Name der fehlerhaften Anwendung: bds.exe, Version: 28.0.48361.3236, Zeitstempel: 0x6424f70a
Name des fehlerhaften Moduls: madExcept32.dll, Version: 4.0.6.0, Zeitstempel: 0x654bc346
Ausnahmecode: 0xc0000005
Fehleroffset: 0x000a6664
ID des fehlerhaften Prozesses: 0x0x6788
Startzeit der fehlerhaften Anwendung: 0x0x1DA434606F38B7D
Pfad der fehlerhaften Anwendung: C:\Development\Delphi\Alexandria\bin\bds.exe
Pfad des fehlerhaften Moduls: C:\Development\Delphi\Extensions\madCollection\madExcept\Dlls\madExcept32.dll
Berichtskennung: 409c1fdd-db65-45fa-b78c-2a999ad13621
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:

For the moment I can just start the Delphi IDE, if I uninstall madExcept or rename madExcept32.dll. As I don't want to reinstall Delphi with components and extension I guess that my next step is trying to go back to a disk image backup before the update. But not today.

[madshi]

madExcept32.dll is only used for leak reporting and the "instantly crash" feature. So it seems that some BPL that is loaded in the IDE tries to activate leak reporting and/or "instantly crash". Which is definitely not default behavior for madExcept. Do you have any of your own BPLs loaded in the IDE? Did you enable madExcept for any of them? If so, did you maybe accidently activate leak reporting or "instantly crash" for them?

[masc]

Hi,

Thank you very much for your quick reply. I gradually removed the BPLs that were added after the installation of madExcept 5.1.3 (fortunately not too many) and yes - at some point I was able to load the IDE including madExcept and its madExcept32.dll.

In my case it concerned the Virtual TreeView component. I deleted the Virtual TreeView folder and installed it again. When opening the project group "Packages\RAD Studio 10.4+\VirtualTreeView.groupproj", madExcept is activated for the projects VirtualTreesR280.bpl and VirtualTreesD280.bpl and is therefore included in the compilation and installation.

I have now deactivated madExcept in the project settings before creating/installing the Virtual TreeView projects.

Since then the start of the Delphi IDE also runs with the current release of madExcept.

What is perhaps a little strange is that the IDE ran without any problems with the old BPLs of Virtual TreeView in the last few months and the problem first occurred after the update of madExcept. But that won't keep me awake at night. My IDE is now working again - with madExcept and Virtual TreeView.

Thanks again and have a good start in 2024.