madshi.net

"CrashedThreadID" is meant to be used for crashes, not for freezes. That of course also means that there's no reason for you to call InitAntiFreeze or CloseAntiFreeze in the context of a specific thread you want to be analyzed for freezing, because AntiFreeze doesn't do that, anway. It on...

The frozen state is always detected by the "anti freeze" thread, which then raises an EFrozen exception. That's the whole purpose of that thread. So "GetThreadName(exceptIntf.CrashedThreadId)" works correctly. The freeze detection practically just means that your main thread has...

OK, can you please clarify what the use of exceptIntf.CrashedThreadID is if it just always returns the same threadID as GetCurrentThreadId(), which is what I understand you answer to imply? (The fact that "CrashedThreadID" is the id of the freezechecking thread seemingly suggests that the ...

Hi, Today I tried to modify the bug report email subject to include the thread/client name, within the registered madExcept Exception handler with code as follows: if exceptIntf.ExceptClass = 'EFrozen' then begin exceptIntf.MailSubject := exceptIntf.MailSubject + ' ('+GetThreadName(exceptIntf.Crashe...

Hi, Is it mandatory to call CloseAntiFreeze before or on thread destruction (from the same thread that the InitAntiFreeze was called from), or is it OK to omit doing this and leave it up to the thread destruction? (That is, will thread destruction eventually also cause CloseAntiFreeze to be called a...

Same here.

I think we're seeing the same thing. It's driving me crazy. I'm getting crash reports which have no bearing on what actually happened. This morning was a particular case in point where I was actually the one doing the report (I was VNC'd onto users machine) and to my surprise when I checked the repo...