What does RtlInitializeExceptionChain do, and how

Question

I am trying to find bottlenecks in my program (currently in the "low-hanging fruit" stage), and using a profiler I get something like the following:

The thing I see in this is that RtlInitializeExceptionChain takes up the far majority of the time, and functions from my actual program don't even make it onto this top list. I would like to know if anyone knows what RtlInitializeExceptionChain does, how it is called, and how I can reorganize my program to not call it so much?

Some other information about my project: it is a COM API using ATL, and the program being profiled is a "testing" C++ program which consumes this API.

Thanks!

Answer 1

This can happen in the Very Sleepy profiler if choose "Profile All" [Threads] instead of "Profile Selected" [Threads]. There can easily be threads that are doing mostly waiting, and this gets mixed into the profiling results. I've been thrown by this a few times as well.

Answer 2

RtlInitializeExceptionChain is an internal function in the Run-Time Library, a collection of kernel-mode support functions used by kernel-mode drivers and the OS itself. It's kind of the kernel-mode version of the C run-time library.

If your application is 32-bit and you're profiling it on a 64-bit machine, profiling it on a 32-bit machine or building a 64-bit version will probably move RtlInitializeExceptionChain out of the top 10 list since it's always used in thunking.

Otherwise, there's almost certainly nothing you can do about it.

Answer 3

As far as I know RtlInitializeExceptionChain gets called once for each thread that gets created, as part of its initialization. The function sets up SEH for the thread.

Since it appears to be costly time-wise (not sure why, since it doesn't appear to be doing much), confirm whether you have many threads in your application, and potentially see if you can decrease the number of threads while still doing what it needs to do.

Either way, this is a function that's internal to the operating system, and it's out of a developer's direct control except for the fact that it will be involved in the initialization of threads the developer has started.

Answer 4

I found this page googling the same problem, and thought I should add my solution.

I was finding an application suffering severe slowdown which I traced to this function using a profiler.

Turned out I had left a VS conditional breakpoint on which was getting tested constantly but not triggering. Removing the breakpoint fixed the issue.