madshi.net

Doh - I looked at the madExcept source code and figured it out.
I needed to copy madExcept32.dll and madExcept64.dll onto the Regressions machine and ensure they were in the PATH.
That's probably documented somewhere but I'd never read it.

Hi all I've been trying to track down an intermittent heap corruption issue that occurs on our build machines when they run our full regressions suites. I've built an executable with the madExcept 'crash on overrun' feature turned on and it happily runs in that mode on my laptop, and I can see the e...

Upgraded to 5.0 and my issue is indeed fixed. I'll let you know if any regressions emerge but I'm pretty optimistic looking at the nature of the change.
Thanks a lot for your prompt attention to this, as always, Matthias.

Awesome. Did you do the change in madExcept 4.x or 5.x?
I haven't switched to 5.0 yet - it's on my todo list, but I could if needs be.

Sorry, for the slow reply. I wasn't notified of your reply which is probably my fault for not checking some button.

HandleMessagesInMainThread is True as that seems to be the default. It's Delphi 10.1 Berlin.

We had a strange report about funny chevron characters turning up in our edit controls rather than tabbing to the next control but it only happened intermittently. We eventually tracked it down to only happening when there is a madExcept exception dialog showing which hasn't been actioned yet i.e. c...

This DLL helper thread shutdown dilemma is one I've seen Raymond Chen of Microsoft blog about a number of times.

https://devblogs.microsoft.com/oldnewthing/?p=19233
https://devblogs.microsoft.com/oldnewthing/?p=99675
https://devblogs.microsoft.com/oldnewthing/?p=2733

Ah yes, not 64-bit safe. Fixed.

We've recently discovered that using GetSystemMetrics to detect Terminal Services remote sessions is no longer sufficient per Microsoft. <sigh> https://docs.microsoft.com/en-us/windows/win32/termserv/detecting-the-terminal-services-environment It's been this way since Windows 8/Server 2012 when Remo...

After a bit of debugging, I've determined that madExcept is getting the stack overflow exception and marshaling it to the madExcept thread but then Windows dies whilst trying to pump the message loop that waits for the dialog in the madExcept thread. If I turn off the undocumented HandleMessagesInMa...

I'm using madExcept 4.0.17 and Delphi 10.1 Berlin. We have a subscription to madExcept 5.0 but I've not gotten around to switching over our main application to use it. My bad. Based on a report from the field, I wrote a simple single form test application that causes a stack overflow due to recursio...

Hi I was examining a 64-bit madExcept bugreport where the disassembly shows an Access Violatiom in a routine where the 3rd parameter being passed in a Delphi enumerated value which is contained in a byte - TCollection.RemoveItem on the line where it calls Notify(Item, cnExtracting) if you care and r...

OK. It's all good now and in fact apparently faster with 'hidden' 64-bit exceptions that 4.0.12 is in our tests. It's definitely the IsBadReadPtr cs. VirtualQuery change in IsValidObjectEx that makes a noticeable difference. However, I did end up making the following change to HandleCreateThread sin...

Ah yes, we do have the aforementioned handler and indeed, it does access exceptIntf.BugReport on that line. I don't know about the 'please wait' - I don't recall seeing it but firing our nested exception test does indeed take a few seconds to produce the madExcept UI. We use the handler to add a bun...

OK - now that's much better! We haven't done exact timings (we can if you'd like) but performance feels to be back in line with the earlier builds. Awesome - thanks for the attention to this Mathias! If I could just figure out why my nested 64-bit exception stack traces go off into the weeds (raised...