madshi.net

No need to copy madExcept64.dll in with madExcept32.dll name. You can simply rename/delete madExcept32.dll. It's not needed. It's only used for leak reporting and/or the "instantly crash" feature, it's not used for anything else. And if it's not there, everything will still work, only the ...

I've seen a similar report previously. The issue is this: The "madExcept32.dll" file is not supposed to be loaded into the IDE. It is loaded into the IDE only if there's a package loaded in the IDE which was compiled with either leak reporting or with the "instantly crash" featur...

Do you have any self-written IDE packages installed?

That's really weird. The problem is that it's hard for me to do anything, or even debug the problem, because I can't reproduce it on my PC.

Would it be too much to ask to try uninstalling and reinstalling Delphi 12? I remember that one user did that at some point and it helped with some issue.

This seems to be a very rare occurring, I think you're only the 2nd user who has reported such a problem to me so far. How does it crash? Do you get a madExcept crash report? Or a Delphi crash report? Or does it silently exit? It could be some kind of incompatibility between the madExcept IDE extens...

Glad to hear that!

For a new project in newer Delphi versions, I've noticed that sometimes you need to enable madExcept, save the project, close the project, reopen the project and then it's fine. That wasn't necessary in older Delphi versions. Not sure why this has changed.

It's strange, though, that kuaaan has a driver which is prepared for the longer key size, but not a matching madConfigDrv.exe. Not sure how that happened. I'm pretty sure I updated both the driver and the madConfigDrv.exe at the same time, to support longer key sizes...

Thanks iconic!

@kuaaan, if you send me an email, I can make the newer madConfigDrv.exe available to you separately.

I can reproduce the issue with Delphi 7, but there's really not much I can do about it. The tricky thing is that we want leak reporting to be done at the *VERY LAST* thing in your process. If we do it too early, e.g. let's say we do it just before the "finalization" section of all units ha...

I've copied all the files into one folder, then ran this command line: "madConfigDrv.exe renameme64.sys funnyName -unsafeStopAllowed -cert=pmon.dll" However, I've overwritten the madConfigDrv.exe with the latest version, because I didn't want to execute some EXE I downloaded from the inter...

Ok, I thought it would be a thread still being active, and now it seems to have been some window instead, maybe. In any case, usually madExcept's leak reporting only starts when the application is already nearly shutdown. So if any code still crashes afterwards, that would point to probably some cod...

The driver wants to check if the DLL that it is asked to inject is "trustworthy" or not. Because if the driver didn't do that, malware could misuse the driver to inject malware dlls. We definitely don't want that! So because of that the driver has to have a way to verify if a DLL is trustw...

I don't think activating leak reporting is a good idea in your specific situation. Leak reporting almost never helps tracking down the cause of exceptions. Leak reporting is for finding issues with high memory consumption, or your application running into "out of memory" exceptions. For ot...

First of all, does loading the driver succeed? That's the first step. The "The driver file does not support storing trusted certificates" suggest that you might be using an outdated driver file? Please make sure you use the latest driver from the latest installer: http://madshi.net/madColl...