Post Build Event Fail

[choochy2003]

I just want to bring an issue to your attention regarding Post build events. I run Signtool on post build to sign all my executables, but it seems that in Delphi XE2 with the latest MadExcept release, this post build fails. If I disable MadExcept completely for the project the post build is always successful.

I am not sure if this is a Delphi IDE issue or a timing issue with MadExcept.

Regards

Chris

[madshi]

Did this work with older Delphi versions? madExcept does patch the freshly compiled exe file, in the moment when the IDE tells madExcept that the compilation has succeeded. But I don't really see why that would make problems with other post build stuff. Can you give me more details on "fails"? Do you get a bluescreen? Does your computer explode? You know I need more information than just "fails".

[kobik]

Does your computer explode?

LMAO!

[nminkov]

Hi,

I am currently experimenting madexept in our product and have the same issue using C++ Builder XE4.

We have a postbuild script that creates a crc and other stuff of our exe, which the exe afterward check and fails because madexep code has been added, but only after our build script has been executed.

So the question is, there a way to tell madexept to execute a postbuild event after has done its magic, or better, force madexept to apply its code before RadStudio post build event has been called (proper logic)? That is, our post process script must always run at the end (we won't use madexept CRC check).

A work around is to execute our script manually, but its big stopper for us.

Thanks

[madshi]

Unfortunately I don't have control over the order in which the IDE calls madExcept and the post build events. It seems that for your specific purpose the order is bad. For other people it might be good. In any case, I have no control over that.

What you could do is one of the following:

(1) Remove madExceptWizard_.bpl from the IDE. Then add another post build event which calls madExceptPatch.exe to do what the wizard normally does. The disadvantage of this solution is that you lose the madExcept settings dialog.

(2) Add a comment "// dontTouchUses" to your project/cpp file to stop madExcept from removing the "#pragma link" commands. Place this comment directly in front of the #pragma link lines. Afterwards disable madExcept in the settings dialog for the project. After doing these changes the madExcept code is still linked into your exe file, however, you still need to add a post build event to run madExceptPatch.exe. For madExceptPatch.exe to do its job, the YourProject.mes file needs to have madExcept enabled, though. So you may want to make a copy of the "enabled" mes file and use that for calling madExceptPatch.exe. This solution is more complicated than (1), but you still have the madExcept settings dialog available.

Does that help?

[nminkov]

Thank you for the quick response,

Its far from ideal. The for us will be much better to have an option in madExcept settings "run manually", which activates mad exception, but requires call to madExceptPatch.exe to apply it.

Other useful options will be to have Debug and Release configuration. E.g. memory leak check is great to have it activated all the time in Debug, but we don't want it in Release.

Haven't finished reading the doc, bug have not found yet answer yet to this: How can I deactivate fully the madExcept dialogs? I want mad except to be silent, log to file that changes on every execution (my file name generation policy).

I can see that I can register my exception handler and there save the report the way I want it. (probably an answer to my comment). However, will this handler also be able to handle and process properly "Abnormal program termination" (esBcbAbnormalProgramTermination)? Generally on esBcbAbnormalProgramTermination, what code can I execute safely (any?).

Thanks

[madshi]

I don't want to make the options dialog more complicated for something that only one in a thousand users will need. But I could imagine adding a registry setting or a custom field in the MES file to disable madExcept patching. Oh wait, I have a better idea: If you call madExceptPatch manually in a post build event, the madExceptWizard could simply detect that and then skip exe patching. What do you think about that?

In order to hide all dialogs, uncheck the option "show please wait box" here:

http://help.madshi.net/madExceptSettings2.htm

And change the bottom right combobox to "don't show anything" here:

http://help.madshi.net/madExceptSettings3.htm

You can at runtime modify the bug report file path by doing "MESettings().BugReportFile := 'c:\whatever\fileName.txt';".

You can do pretty much everything in your "esBcbAbnormalProgramTermination". I'm not aware of any specific limitations.

[nminkov]

Great, that was quick an easy solution.

When getting esBcbAbnormalProgramTermination, my program is still running or I have no longer control over it? That was actually my question about what I can do.

Thanks for the quick and efficient help

[madshi]

Your esBcbAbnormalProgramTermination handler is called *before* your program is terminated. So everything is still up and running at that moment. The program will be terminated only after your handler has returned.

[nminkov]

Thanks madshi!

[nminkov]

Hopefully last question.

I am trying to custom log the exception, but can't figure how get just the call stack of the thread in which the exception occurred.
IMEException exposes CrashedThreadId , ThreadIds and Callstacks. From what I can understand, I need to match CrashedThreadId to ThreadIds[n] for the proper index which I an use in Callstacks. But how do I enumerate ThreadIds without generating out of bounds exception, there is no Count/Size of number of threads method/property?

[madshi]

Simply use the first BugReportSection, that should contain the callstack of the crashing thread.

[nminkov]

Thanks,

That's what I am currently doing, however need to search for the proper section by thread id (I am doing it).

So there is no easy way to get Callstacks/ThreadIds count?

[madshi]

Sorry, I don't understand what you want. You said you wanted: "call stack of the thread in which the exception occurred". And that's exactly what you get from the first BugReportSection. If you want something else, you need to be clearer about what you want.

[nminkov]

BugReportSection works as you suggested. My question about Callstacks/ThreadIds is how do I iterate them if I need to access call stack details to create my proper log format.