Hooked Stacks are not walkable

[justinstenning]

Moved from CodePlex
Originally submitted by Alois

Easyhook is a great library which I have used for x86 programs with great success to hook into OS methods to find handle leaks and such things.
I did basically hook e.g. MapViewOfFile and write out an ETW Event with the method arguments. The same for UnmapViewOfFile. With Windows Event Tracing I get a nice ETL file which I can open with WPA and directly see where the leaks might be hiding.
This is a great way to find leaks of pretty much anything without slowing down the application like a debugger does with breakpoints and logging the call stacks.
Under x64 Win 8.1 the ETW stackwalker is not able to walk the stack so the call stack ends at my hooked method which is unfortunate. It looks like interceptions method Easyhook uses to hook methods is not exepcted by the stackwalker to further traverse the stack.
I wonder if there is a way to make Easyhooked method more ETW stackwalk friendly so I can get the best of both worlds.

Comments from CodePlex

Alois wrote May 8 at 3:31 PM

I have got word from MS that for hooked methods one needs to add Unwind information to the hooked methods.

The OS needs to have the 64 bit unwind information in order to unwind a stack frame. If you inject new methods, you need to also register the unwind information associated with it. There were already APIs for doing this, but it expected you to register a complete Function table (for an entire module) all at once. For JIT compilation we needed a way of specifying this information incrementally as methods are JIT compiled. We used these new Win8 functions to do it.

RtlAddGrowableFunctionTable
RtlGrowFunctionTable
RtlDeleteGrowableFunctionTable 

Since the CLR is open source now we could use this like the JIT compiler does it here:

https://github.com/dotnet/coreclr/blob/master/src/vm/codeman.cpp

Has anyone experience with such stuff?

spazzarama wrote May 8 at 11:02 PM
Looks interesting, it would be helpful to have a cut down simple test project to use to test with, any chance you can attach something here? Thanks

Alois wrote May 12 at 3:56 PM
Yes I will make a small sample to repro the issue. Currently I am quite busy. Give me a week to come up with a sample.

Alois wrote May 15 at 7:33 AM
I have edited FileMon.exe of your samples with an custom ETW Provider.

See https://drive.google.com/folderview?id=0BxlmobpeaahAMllKamt3LWxheXM&usp=sharing

Under Source\Build\netfx4-Debug\CreateFileLogs.etl is an ETL file which shows the issue. Additionally in the shared folder is a Screenshot of WPA.exe looking at the call stack which ends in the middle.

The current implementation of FileMon compiles only for x64. I hope this helps to reproduce the problem and if you can add the corresponding exception handler unwind information to EasyHook it would be really helpful.

Alois wrote May 27 at 5:12 AM
Dies the sample work for you? If you have problems to get it running drop me a note.

Yours,
Alois Kraus

[Alois-xx]

I have added x64 Unwind Infos for the dynamically generated code by myself. I will upload a fork when the code is more polished. I had to rearrange the trampline assembler code quite a bit. Now it has a frame pointer to make the stacks walkable but the performance impact should be still minimal.
You would not believe how much research this required to get it working.

[justinstenning]

You would not believe how much research this required to get it working.

Oh I believe it! I look forward to seeing it!