full support for 64bit OSs

The complete functionality of madCodeHook now fully supports 32bit and 64bit processes on 32bit and 64bit OSs.

safe driver based system wide DLL injection

With madCodeHook 2.x every application using madCodeHook shared the same driver. This could create reliability issues and security issues (misuse by malware). With madCodeHook 3.x every application using madCodeHook has its own separate driver, which is always limited to inject only "known" DLLs, and which is signed by the application company's own certificate. This should protect the driver based injection from malware misuse. There's a new separate API set available now for controlling the madCodeHook 3.0 injection drivers.

black & white lists for DLL injection

System wide DLL injection can now be controlled by providing a black and/or white list. These lists can contain any numbers of exe file name paths/names. Wildcards ("?" and "*") are supported in both path and file name.

支援開發工具

madCodeHook supports Delphi 4-7, Delphi 2005-11 (32bit and 64bit), Borland C++ Builder 5-6, Borland C++ Builder 2006-11 (32bit only for now), MSVC++ (32bit and 64bit).

Hooking Rules

When doing API hooking you need to follow some basic rules. If you don't follow them, your API hooks might make things unstable. Here's a list of the most important rules:

1. Always use *exactly* the same parameters, the same result type and the same calling convention for the original API, your callback function and for the "NextHook" function variable.
2. In a hook DLL only do what is absolutely necessary. Try to keep things as short and simple as possible. In Delphi avoid the VCL. In MSVC++ avoid MFC/ATL.
3. Be careful what you do in your hook DLL, if you plan to inject it into NT system/service processes. You're not allowed to do any GUI stuff (e.g. FindWindow, PostMessage, MessageBox, etc) inside of a non-interactive system process. If you do nevertheless, things like sudden OS reboots can happen. Check out madCodeHook's Tool Functions. They can tell you in what kind of process your DLL is currently running. If you need to do inter process communication, please use madCodeHook's IPC functions instead of FindWindow/PostMessage.
4. In your hook DLL link to as few DLLs as possible. Avoid linking to RasApi32.dll, because NT 16-bit processes will otherwise tend to crash when being started the first time. Linking your DLL to oleaut32.dll will make "Paint" crash in win95. However, this problem can be fixed by applying this patch: http://support.microsoft.com/support/kb/articles/Q162/5/00.asp
5. Make sure that your hook callback function does not accidently alter the Get/SetLastError value. You may alter it, if you want to signal a failure. But if you are calling the next hook and don't want to impact the flow of things, please make sure that neither you nor any of the functions/APIs you're calling messes around with the last error value. Some APIs like CreateMutex do change this value. So if you call CreateMutex inside of your hook callback function, please save the last error value and restore it afterwards. The madCodeHook Tool Functions are last error neutral.
6. Each API hook needs its own callback function and its own "NextHook" variable. Don't try to save code by using callback functions and/or NextHook variables twice.
7. In winNT in hook callback function of wide APIs (like e.g. GetModuleFileNameWCallback or CreateFileWCallback) don't do anything which results in the OS trying to convert ansi <-> wide strings. Don't let Delphi automatically convert ansi <-> wide strings for you. Don't ask Windows to convert strings for you. Don't call any ansi APIs (this internally results in ansi <-> wide conversion again). Instead use the madCodeHook Tool Functions to convert strings. This rule doesn't apply to win9x. Also it doesn't apply to ansi hook callback functions in winNT. It only applies to wide hook callbacks in winNT.
8. In the initialization of your DLL avoid to directly or indirectly call VirtualAlloc, because otherwise in winNT 16-bit processes will tend to crash.
9. Avoid creating threads and windows in a hook dll.

This all might sound complicated and difficult. But hey, after all API hooking *is* a difficult thing. madCodeHook tries to free you from all problems as far as is possible. But the rules mentioned above can not be controlled by madCodeHook. Those are general hooking rules which are valid regardless of which API hooking method or package you're using and I can't change that.

You have to understand what happens when you hook an API: You are violently breaking into the flow of a program, which someone else has written. This other programmer has not intended that you do that, nor has he even calculated with that. That means you have to be very careful that you don't break his code. You have to try to not change anything which could bring the original program into problems. Try to change only what is necessary, not one bit more.

You can violate some of the rules without big impact, if you're only hooking one specific process. You should then test things deeply, but if no problems arise, it's okay. However, when doing program independent system wide API hooking, things are different. It's totally impossible to check your hooking stuff against all existing programs in the world, there are just too many to check them all. So you can just follow the rules and hope that your hooks don't break anything. But hey, if you are careful, thing are looking quite positive. So don't worry too much about these things. Just make sure that you follow the rules.

madExcept 可以幫助您在您的軟體中找到bug。每當有當機或異常在您的程式發生時，madExcept會自動捕捉它、分析它並收集大量有用的資訊，並向您發送一份完整的錯誤報告。 madExcept也能為您找到記憶體洩漏(memory leaks)、資源洩漏(resource leak)和緩衝區溢位(Buffer Overflow)。

Do you know this box? ;-) Well, nobody is perfect. So it happens from time to time that we programmers ship a product, which is not totally bug free. That's okay (more or less), you might say. As long as your product has less bugs  than Windows, it's fine.

But what do your customers say? Let's say a customer mails you that he gets this "invalid pointer operation" box quite often and that he either wants his money back or a new version which fixes this bug. He's willing to help you finding the bug, he even sends you a screen shot of the exception box. But does that really help much? I don't think so. There's absolutely *NO* useful information in that box. And on your computer this bug simply doesn't occur, no idea why. So what can you do now?

What you would really need is more information - a *lot* more information. You would need the exact source code location where the exception occured, and - also important - how the program got to that location. In other words: You need the exception callstack, with unit name, function name and line number for each item. THEN you would have good hope to find the bug. Right?

Okay, the package "madExcept" was exactly build for that purpose, namely to replace Delphi's standard exception handling with a new logic, which finds out the full callstack with as much details and infos as possible. The exact behaviour of madExcept's exception handling can be totally customized. You can choose whether you want to see an exception box or not, how the box should look like, which buttons it should have, how the buttons should be labeled and so on. If you don't do any customization, the default box looks like this:

The usual customer doesn't really want to read madExcept's detailed bug report. He just wants to send the bug report to the programmer, hoping that this will lead to a corrected new version. So in the default settings madExcept's box doesn't show any exception information, not even the exception message itself. The customer can just mail the bug report, or he can continue, restart or close the application.

One thing should be mentioned here: madExcept's exception box is *not* using any VCL stuff, instead it's build on pure win32 API calls. It's no fun designing a nice box with bitmap buttons and so on with win32 APIs only, but in this case it was absolutely necessary. The VCL is not thread safe, but our exception box must be able to show up in the context of each thread - thus it has to be thread safe, thus it must not use the VCL.

Apart from pure exception handling madExcept does one more thing (if you want it to), namely checking whether the main thread is frozen or not. Sometimes your program doesn't react anymore, although no exception occured. That can happen e.g. if your main thread runs in an infinite loop or if there's a bug in the synchronization of multiple threads, with the result of a dead lock. Such a bug can be *very* difficult to find, because your program is just frozen, without showing an exception. But with madExcept the situation is not that hopeless anymore: If your main thread doesn't react on messages for a specified time, madExcept raises an exception in the context of the main thread. In the resulting bug report you can see what the main thread was doing exactly and also what all other threads were doing at that time. That should help a lot finding infinite loop and dead lock bugs.

更新介紹

· added support for updated Delphi 11 64bit map file format
· added support for new Delphi ASLR feature
· optional support for Delphi's HTTP uploader
· made "system up time" more reliable on newer OSs
· added support for detecting/reporting Windows 11
· undocumented "AddFontSize" variable allows increasing GUI font size
· undocumented "StackDumpLines" variable defines memory dump size

madExcept supports Delphi 4-7, Delphi 2005-11 (32bit and 64bit), Borland C++ Builder 5-6 and Borland C++ Builder 2006-11 (32bit only for now). Unfortunately MSVC++ or other C++ compilers are not supported at this time

• no need to distribute additional files, cause madExcept is fully linked into your executable
• the size of your executable file grows only by some percent (usually single digit)
• you don't need to change a single line of code in your project
• there's no performance loss, as long as no exception occurs
• full support for multi threaded applications
• full support for third party translation tools
• full support for third party protection/compression tools
• email, web upload and printing functionality included
• free for non-commercial usage, inexpensive for commercial usage