madshi.net

Sure.

That's fine, I don't mind.

You can use "exceptIntf.BugReportSections[0]" instead. This will be the crashing thread, which is usually (but not always) the main thread.

Is it not your own EXE file? Or what is the reason you want this to independent of the EXE file? Do you want bug reports to be created only for crashes in your own DLL or also for crashes in the EXE file?

The installer should add the packages madBasic_.bpl, madDisAsm_.bpl, madExcept_.bpl and madExceptWizard.bpl to your IDE. Can you check your list of installed IDE packages to see if these are listed? Maybe they are unchecked? If they are checked, you should have a menu item "madExcept Settings&q...

I'm sorry, I've no experience with Linux.

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 BP...

Is it a 32bit or 64bit application? In 32bit, it's very easy to run out of RAM, especially when using leak reporting. Anyway, your original problem does not really indicate a leak, I think instead it indicates that you probably have a secondary thread that is still running while your application is ...

I don't think so. madExcept itself doesn't know, either.

Yes, of course.

Same!!

You can very easily add it yourself: unit AddPlatformToBugReport; interface implementation uses madExcept; procedure AddPlatform(const exceptIntf: IMEException; var handled: boolean); begin {$ifdef win64} exceptIntf.BugReportHeader['platform'] := 'x64'; {$else} exceptIntf.BugReportHeader['platform']...

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...

When loading which BPL exactly? Is it a "naked" Delphi 12 installation, with no other 3rd party packages installed yet? Or do you have other 3rd party packages installed? I'm wondering if it might be some sort of incompatability with other 3rd party packages? Also, could you please verify ...

That might mean that the DLL is not recognized by the driver. Can you confirm that the driver is actually running?

Did you sign the hook DLL at all, or not? If so, did you sign the hook DLL before or after calling madConfigDrv?