mgrier's WebLog

Canonical Function Structure

2006-10-02T21:50:00Z

Here is a proposed canonical structure for functions/procedures. Clearly in some cases some sections would not be present. What’s important is to understand the basic phasing of the work to be done and the separation of tasks.

int foo(

char *StringIn, // “in” parameter

size_t BufferLength, // “in” parameter

char Buffer[], // “out” parameter, max length governed by BufferLength

size_t *CharsWritten // “out” parameter, must be <= BufferLength

) {

// Phase 1: Initialize out parameters

*CharsWritten = 0;

// Phase 2: Capture and validate parameters

const size_t StringInLength = strlen(StringIn);

if ((BufferLength != 0) && (Buffer == NULL))

return ERR_INVALID_PARAMETER;

// Phase 3: do work

if (BufferLength <= StringInLength)

return ERR_BUFFER_TOO_SMALL;

memcpy(Buffer, StringIn, StringInLength);

Buffer[StringInLength] = ‘\0’;

// Phase 4: copy data out

*CharsWritten = StringInLength + 1; // safe because BufferLength is > StringInLength so “+1” won’t overflow

// Phase 5: goodbye

return ERR_SUCCEEDED;

}

There may be other phases and the example’s perhaps kind of dumb but I think it works well to call out what kinds of operations should happen in which phases and even more so what doesn’t have to happen later on given work that occurred earlier.

The NT DLL Loader: FreeLibrary()

2005-06-29T08:39:00Z

Let's review the loader's modus operandi and derive the (once again simple!) rules for what the heck is going on.

When someone calls FreeLibrary(hInstance), the loader walks the closure of the dependencies for the module/instance in question and if their refcounts are not maxxed out ("pinned"), they are decremented. Any modules whose refcounts are now zero are marked for unload. This means that the loader finds all of those modules in the in-initialization-order list and runs their DLL_PROCESS_DETACH callouts in the opposite order of initialization. Notice that the return value from DllMain() is ignored for DLL_PROCESS_DETACH - you cannot do anything which could fail. After shutting down all those DLLs, they are unmapped and FreeLibrary() returns.

Notice that the ordering dragon reared its head again but also notice that as long as your init order made sense, it's very likely that your uninit order makes sense also so you tend not to hit so many problems here w.r.t. ordering. Most LoadLibrary()/FreeLibrary() ordering issues are found in the LoadLibrary() path, not the unload path. (In fact I can't recall a single instance of FreeLibrary() inducing a DLL_PROCESS_DETACH [basic] ordering issue. Not that you can't imagine it but I can't recall ever having such a problem and as you know I like to talk about problems.)

Reentrancy problems tomorrow... Just imagine, given this information, what happens if someone calls LoadLibrary() during DLL_PROCESS_DETACH...

The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - wrap up

2005-06-29T05:45:00Z

Hopefully the culmination of these cautionary tales is clear: you're walking a very fine line when you attempt to reenter the loader from within a loader callout. You're (more!) subject to ordering and cycle issues, you can force initialization to proceed on to your dependencies even if you're not ready for them to call in to you and failure to propagate failures from the loader is fatal.

Spot the bug that corrupted/crashed your process:

if (GetFileAttributesW(pszSomePath) != 0xffffffff) {
// process the file
}

Where was it? Oh, right, GetFileAttributes might actually be a linker delayload! So it's actually an invisible wrapper around calling into the loader! And I didn't remember to propagate loader errors! Hmm... how do I even know that the error code was a loader error?

I consider this class of bug to be unstomachable. Looking at the souce it seems obvious that there's a bug there. At least you should be looking for ERROR_FILE_NOT_FOUND / ERROR_PATH_NOT_FOUND, not just treating all errors as file not found. But who says that those errors are not propagated out of the delayload stubs in the case that the load failed? (This particular case is arguably obtuse; GetFileAttributesW is in kernel32 which will already have been loaded and initiailzed but the point is still valid.)

I'll provide an in-depth wrap up of all the general cautions and what to do about them but this series should make you feel very very nervous indeed if you have code in your DLL_PROCESS_ATTACH that's doing much more than calling InitializeCriticalSection().

The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 4 - ramifications of questionable quality

2005-06-28T17:41:00Z

Last time I alluded to the world of hurt you're in when the loader is reentered during DLL_PROCESS_ATTACH and the initialization of another DLL failed.

The state of the affairs is pretty derivable from the clues that I've left behind in the series.

First, we know that the loader tracks entry into the initialization function. Otherwise the recursive/reentrant usage of the loader would have just called the same function. Once it sees that an init function has been called, it will not call it again for initialization.

So, in the context of the example from last time, foo.dll's initializer failed. The loader had marked it as entered. The failure was not propagated. Even if the example code was better and called FreeLibrary() to release the library in the case that GetProcAddress() failed, the refcount of foo is still non-zero so it stays loaded.

The next behavior is entirely predictable. When the loader returns back to the outer LoadLibrary() (which was in the middle of initializing all the uninitialized DLLs in the initialization list), it continues on and is very nice and careful not to call any initializers which have not already been called.

Now, foo.dll is loaded, it is not initialized and its initializers will never be called. Nonetheless since the failure was lost it tries to make progress.

Aside:

The obvious suggestion is to track the fact that the init failed and fail the entire load sequence. But that's not really possible; you have an arbitrary number of levels of reentrancy here; making this a failure case now when it didn't used to be will break applications. Once again the black helicopters swoop in and accusations that Windows only tries to be compatible fly around. Most of all, you've caused an app compat hit by disallowing something that's always been documented not to work.

Now, let's see. I can spend let's roughly cost it to 320 person-hours dealing with the arguably better but incompatible change I made or I can just let it be and continue to advise against the whole pattern.

Like I said, while it was a fun ride maintaining the loader for a period of time, it was also a little slice of hades too.

Now clearly this behavior needs to be called out better in the documentation. These blog entries are an attempt at shedding light on the topic focussing mostly on directly observable behavior rather than "contractual obligations". (app compat turns observable behavior into contractual obligations but app compat is also dialable given the intestinal fortitude and free time to do it.)

Note that this problem is about the closure of the call graph during the duration of the DLL_PROCESS_ATTACH.

Next time, wrapping up DLL_PROCESS_ATTACH reentrancy and then setting the stage for DLL_PROCESS_DETACH issues.

The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 3 - quality requirements

2005-06-25T02:23:00Z

Now we're loaded for bear! We understand how PEs which are either launched via CreateProcess() or loaded via LoadLibrary() are the roots of directed cyclic graphs. Each new graph is turned into a linear initialization-order list where nodes further from the root are initialized prior to nodes closer to the root. Cycles in the graph are resolved based on where you first enter the cycle and thus depend on the entire graph (not just local DLL-to-DLL relationships). Dynamic loads during initialization are often handled correctly but they themselves can introduce additional cycles. There is less opportunity to fix this up since the dynamic load results only in new additions to the initialization list.

Great. Seven impossible things already done (I guess they weren't really impossible, but then again maybe they weren't really done either, eh?) let's see where things start to get really messy.

Dynamic loads during initialization lead to a couple of very interesting things. First, recall that the initializer that was in progress isn't re-run when GetProcAddress() is called. That's going to be important.

Let's go back to my sleazy little attempt to call a function here: (let's assume this is in bar.dll; it's not going to be very important but given all the players it's going to get confusing...)

    case DLL_PROCESS_ATTACH:
        SOME_FUNCTION_PTR_T pfn = (SOME_FUNCTION_PTR_T) GetProcAddress(LoadLibraryW(L"SomeOther.DLL"), "SomeFunction");
        if (pfn != NULL) (*pfn)();
        break;
    }

We didn't check the return status from the LoadLibrary() call. Since LL() doesn't run initializers let's assume that that's OK in this context. I'll assume that GetProcAddress() fails with an invalid argument and thus still returns NULL. We do check the result of GPA() and don't call through the pointer if it's NULL so hey, nobody got hurt, right?

The LL() non-check is dubious. Do you know why LoadLibrary() failed? If it failed because of out-of-memory maybe it's the wrong thing to press on. I digress; this is more of a usual topic for my blog rather than focussing on loader related issues. But it's about to become a loader related issue.

Let's say that foo.dll was already on the init list, after the current DLL. Let's assume that its refcount was 1. Now SomeOther.DLL maybe statically imported foo.dll also. Now it's (foo.dll's) refcount is 2 after the LoadLibrary() call. Let's write the overall initialization list now:

ntdll.dll
kernel32.dll
bar.dll
foo.dll
somedllimportedbytheexethatusesfoo.dll
someother.dll

The GetProcAddress() call attempts to run foo.dll's initializer (since it has to be initialized before running someother.dll's initializer). Let's assume it fails. These things happen, it's the real world out there. I/Os fail, memory allocations fail, duplicate file names occur, network glitches when trying to open file handles using the redirector, etc.

So, foo fails initialization and properly reports FALSE back to the loader. The loader will propagate this failure out to the GetProcAddress() call. But wait, that darned code assumes that the only reason GetProcAddress() can fail is due to ERROR_PROC_NOT_FOUND!

Care to guess what happens next?

The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 2 - GetProcAddress()

2005-06-23T22:28:00Z

Last time we pondered what does LoadLibrary() do when called inside of a DLL_PROCESS_ATTACH callout. The answer was pretty simple and predictable - the only nuance is that the initializers are not run before returning.

Now place yourself in the position of mythical developer Weve Stoods who evidently did most of the loader development in the early 80s. You cleverly avoided the whole recursive initialization problem. Then a bug report comes in. GetProcAddress and calling through the pointer doesn't work. I've never met Weve myself and I can't say for sure what was going on at the time but I can imagine two scenarios. First, the fact that it does work in some cases (because after all if the library aleady had been initialized due to static imports prior to this case), the team in question "suddenly" has a break where sometimes calling through the function pointer works and sometimes it does not. Second scenario is that "it's so easy to make it work, why can't you just make it work?"

The road to Hades is paved with good intentions...

In both cases, pushing back and saying "GetProcAddress should never be called during DLL_PROCESS_ATTACH" would be a very strange response, even if we might wish now that that was the actual result.

So someone made it work. How did they make it work? Well, we already established that there is an in-initialization-order list that's built up in the loader's internal tables. I believe that this is not an implementation detail - you have to have the single linear/global order because uninitialization on unload has to occur in the reverse order of initialization.

So the simple answer is that within the context of GetProcAddress(), the loader runs all the initializers that have not yet been run up to and including the target module of the GetProcAddress() function.

And you know what? This very often works. Let's assume that we're in a.dll's DLL_PROCESS_ATTACH and it's loading b.dll and calling GetProcAddress() to get the foo() function address. If b.dll depends only on let's say kernel32.dll, well its initializer already ran and is complete before b.dll's initialier is run so b.dll's initializer runs and lo and behold, the b!foo function is ready for business.

But let's say that b.dll, unbeknownst to a.dll, now has a dependency on a.dll. The loader will not attempt to rerun A's initializer and will instead just call B's initializer. Which may call into A. But A didn't finish its initialization! And A had no idea that B depended on it so it wasn't particularly careful about doing all the initialization that B might need before loading B. Boom.

As usual, sprinkle dependency cycles into the mix, stand back and watch the fun.

Next time, we'll look at quality problems with DLL_PROCESS_ATTACH implementations which directly or indirectly call back into the loader. This next topic is a very big part of why I'm so stuck on quality and reliability. Very innocuous errors which people would generally ignore can amplify into terrible problems which are unbelievably difficult to debug.

The NT DLL Loader: DLL_PROCESS_ATTACH reentrancy - step 1 - LoadLibrary()

2005-06-22T23:34:00Z

So what happens if you call back into the loader when you're inside a loader callout (DllMain) for DLL_PROCESS_ATTACH?

I'll be addressing teardown (DLL_PROCESS_DETACH) after completing the DLL_PROCESS_ATTACH series.

The first issue is: what about LoadLibrary()? I'll address GetProcAddress() and FreeLibrary() later.

We already know how LoadLibrary() works. It walks the dependency graph starting from the DLL that is being loaded and trims away any portions already in the loader's tables. It then effectively adds that to the initialization order list and (this is what varies) if you're not using the loader reentrantly, calls the initializers.

If you are calling into the loader reentrantly, the list of DLLs to initialize is extended but (I should double check the code to make sure I'm not lying; it's been a couple of years...) only the outer-most invocation of the loader will complete the initialization sequence.

Thus, you call LoadLibrary("a.dll"). In a.dll's DLL_PROCESS_ATTACH, it calls LoadLibrary("b.dll"). b.dll's initializer is added to the init list but it isn't actually initialized at that time. Instead, the inner LoadLibrary() just returns and then the DLL_PROCESS_ATTACH returns (successfully for the sake of argument) and then the original stack frame for the original LoadLibrary() initializes b.dll.

Clearly things are a little more complicated since it might not be a.dll that actually calls loadlibrary(); it could be a static import of A which does so and thus the init list may still have uninitialied entries on it at the time that the entries for b.dll (and its static imports!) are appended.

So far so good; assuming that the cycles don't break you, this was a fine solution to the problem which also avoids arbitrary recursion due to nested dynamic DLL loads. This was mostly harmless!

The NT DLL Loader: reentrancy - play along at home!

2005-06-22T08:06:00Z

Anyone care to hazard a guess about what happens if you have the following code in your DllMain()? Ignore the leak and the lack of error checking; focus on the what the loader's behavior has to be...

BOOL WINAPI DllMain(HINSTANCE hInstance, DWORD fdwReason, LPVOID lpvReserved) {
    switch (fdwReason) {
    case DLL_PROCESS_ATTACH:
        SOME_FUNCTION_PTR_T pfn = (SOME_FUNCTION_PTR_T) GetProcAddress(LoadLibraryW(L"SomeOther.DLL"), "SomeFunction");
        if (pfn != NULL) (*pfn)();
        break;
    }
    return TRUE;
}

The answer is actually relatively straightforward (the tricky bit is what is GetProcAddress()'s implied contract). I'll do exposition tomorrow. For extra credit, consider what the effect of the leak and lack of error checking is on the loader's internal data tables...

The NT DLL Loader: DLL callouts (DllMain) - DLL_PROCESS_ATTACH deadlocks

2005-06-22T06:48:00Z

The Windows DLL loader (I wasn't around then but I assume some of this even comes from the days of 16-bit Windows) has a feature where a DLL may have an "entry point".

If a DLL has an entry point, the loader calls into it on certain significant events. These events have identifiers associated with them:

DLL_PROCESS_ATTACH
DLL_PROCESS_DETACH
DLL_THREAD_ATTACH
DLL_THREAD_DETACH

I'm not going to talk about the thread callouts any time soon; they probably don't do what you expect them to do so for the most part you should call the function DisableThreadLibraryCalls() in your DLL_PROCESS_ATTACH to save extra page faults when threads come and go.

The apparent contract for DLL_PROCESS_ATTACH is that it is called before any code in your DLL can be called. Sounds like a nice place to do one-time initialization that couldn't be static for some reason.

Note that I said "apparent". Due to the previous articles, if you are involved in a cycle, you can have your code called before your DLL_PROCESS_ATTACH callout has been issued. Maybe you're lucky and you've never been hit by this. There are a lot of lucky people out there.

I'm going to paint a contractual picture here, assuming no cycles are involved.

Presumably if one thread is in the middle of calling your DLL_PROCESS_ATTACH, any other thread that wants to access the exports of your DLL has to block waiting for you to finish your initialization. Let's call this the "mythical loader lock". Maybe it's not so mythical and we can discuss/debate the scope of the synchronization (all DLLs, only the DLLs waiting to initialize, what about cycles?) but let's work out the invariants of the contract before we get too hung up on implementation details.

Thus the first problem with DLL_PROCESS_ATTACH processing is deadlocks. A great example of this is calling CreateThread() inside your own DLL_PROCESS_ATTACH to start a thread running code for your DLL. Clearly the new thread can't start running your code until you have finished your DLL_PROCESS_ATTACH because otherwise we would be breaking the contract. Thus the new thread has to wait for you to exit your DllMain(). Maybe that's OK; if it can just suspend waiting for you to finish up, maybe it fired up and immediately had to block waiting for synchronization but if it doesn't happen too frequently, you can survive this.

But now imagine that you do something nifty and useful in that worker thread. Someday someone comes along and wants to queue a work item to that thread and wait for it to complete. Boom. Insta-deadlock.

That's an easy example, but basically the rule is this:

Calling any function from within your DLL_PROCESS_ATTACH which requires synchronization can deadlock.

Obviously it doesn't have to deadlock; a lot of folks get away with a lot of bad stuff. They're getting lucky for the most part.

A great example is the process heap. Did you know that you can lock it? You can! You can probably have a lot of fun by calling HeapLock(GetProcessHeap())? Why would you do that? I don't know! Who can know? Can we stop it? People want to but just wait for the black helicopter crowd to show up saying that it's really a collusion/conspiracy to get people to upgrade software on Windows.

If someone locks it (or maybe calls HeapWalk on the process heap which I assume locks it for the duration of the walk) and then calls into the loader... well... boom. You're deadlocked.

Those are two easy cases. Clearly you can deadlock in additional ways (RPC calls to another process or machine which have to reenter your process on a different thread which then might need the Mythical Loader Lock) and being creative with things like the thread pool, windows messages, etc. you can come up with a million variations on the theme.

Thus, DLL_PROCESS_ATTACH rule #1:

Don't do anything that requires synchronization. Currently, even heap allocation is suspect.

The NT DLL loader: dynamic unloads

2005-06-19T08:06:00Z

To recap our story from last time:

The NT DLL loader starts from some PE (either the main EXE or the DLL which is passed in to the LoadLibrary() API), walks the graph of static imports rooted with that first PE. You can think of the loader as then building a linear ordered list of DLLs to initialize starting with the deepest away from the root. The order tends to be stable but is dependent on a number of factors which no one DLL can control.

It's not uncommon to find cycles. Any time you try to apply some kinds of topological sort to a graph with cycles you basically have to break the cycles; how you break them typically depends on how you first entered into the cycle. The result of this is that even if a cyclic graph of static imports exists, a linear initialization order is selected. As imports are added and removed from various points in the graph, the first point of entry into the cycle can change and so even though you can experiment and figure out that A is always initialized before B and thus as long as A's initialization does not depend on B's, things work. However an innocuous change elsewhere in the graph can change the order and suddenly the initialization order is broken and your component fails.

For a mental model of dynamic loads, imagine that the closure of the dependencies from the loaded DLL are found and then the DLLs already loaded into the process are removed and the initialization is run in that order.

The global list of DLLs is maintained in multple ordered lists, one of which is the in-initialization-order list. When a dynamic load occurs, the new initialization list is added to the end of the init list.

A few interesting notes. The refcount of the closure of the static imports of the main executable is "maxed out". The refcounting code knows not to decrement load counts when the count is as the maximum value. I call this "pinned" - the DLLs which are in the static closure of the executable are permanently pinned in the process. In theory if you loaded a DLL enough times, its refcount could reach the same value and then it could not be unloaded but if your refcounts get that high you probably have a DLL ref count leak anyways.

The other interesting note is that the refcount of (non-pinned) DLLs is the total number of dynamic loads that could have reached it. E.g. the closure of the dependency graph of the dynamic load has its refcount incremented. This doesn't really matter that much except that when I describe unloading, I'll reference it.

Unloading is pretty explainable: Starting from the DLL handle that was passed in to FreeLibrary(), the refcount of the closure of its dependencies is decremented. Any DLLs whose refcounts reach zero are marked as to-be-unloaded. The in-init-order list is consulted for these DLLs and they are uninitialized in the opposite order of their initialization.

The reason that this is important is that if a DLL managed to get initialized at the right time, it's presumably going to be uninitialized also at the right time. If the uninitialization order was based solely on the graph being unloaded, cycles could have been entered at a different point in the cycle and the uninitialization order could be wrong.

Summary: cycles make initialization order hard to understand but the algorithm picks an order. The order can change when cycles are involved since adding or removing static imports from any DLL in the graph may cause the cycles to be entered at different places. The initialization order is inverted to get the uninitialization order in the case of unloads. DLLs which are reachable from the executable are "pinned" (will never unload). Clients forgetting to call FreeLibrary() will eventually force the DLL to be permanently pinned rather than allowing the refcount to overflow back to zero.

Next time, the hazards of DllMain.

The NT DLL Loader: basic operation

2005-06-18T09:39:00Z

Let's start simply and consider the mythical vertical application (a topic itself for another day). I'm not going to walk through what a PE is or a DLL or an EXE; if you don't know, follow the link or take a gander around MSDN.

Let's call it ccalc.exe (console calculator - no funky graphics, etc. it just uses stdin/stdout). To keep things simple, it only links against the old C runtime library, msvcrt.dll. msvcrt.dll imports functions from kernel32.dll and kernel32.dll imports functions from ntdll.dll.

When the process initializes, the loader figures this imports-graph from the static imports in the PE headers and since code is still sequential, sets up a DLL initialization list which is just a list of DLLs to try to initialize, in order. The initialization is depth first but other than that it's nothing particularly suprising. For this example, the init order would be:

ntdll.dll
kernel32.dll
msvcrt.dll

Not exactly rocket science. ccalc.exe doesn't have an initializer - it has an entry point where its initialization is done prior to passing control to whatever you like to call your main function. (If you don't use the C runtimes, you can tell the linker to use your own function as the entry point but if you do use the C runtime functions, the C runtime needs to get control first so that it can set up its heap, set up the standard streams and do some other various things like set up fp control registers and whatever else it needs to do and then it calls your main() or wmain() function depending on which C runtime init function you set as the entry point.)

Now let's assume you have two teams working on the calculator - one on the "UI" (command line parsing) and another on the logic. Maybe the logic folks want to have a separate DLL. Let's assume that they do and it's called calclogic.dll. This isn't necessarily a good way to do it but let's say that the Super Genius command line parser folks want to use LoadLibrary()/GetProcAddress() to figure out if a function typed in can be used by the calculator logic component. (Insert your favorite reason to use DLLs here; there are a million good ones and two million bad ones.)

But the calclogic.dll SubGeniuses cleverly didn't do all the work themselves. They use bignum.dll to handle all that fancy pants math stuff. Nice job!

So, ccalc.exe calls LoadLibrary() on calclogic.dll. Now what happens?

Bignum.dll is presumably a bignum package and it needs a heap since the representations are variable length. Let's assume that it uses metaheap.dll which they paid a lot of money for but which ends up really just being a big fat wrapper around GlobalAlloc in kernel32.dll.

When the loader sees the load come in for calclogic.dll, it looks at what it imports and figures out what it is importing that isn't already imported into the process. So it looks at calclogic.dll and discovers bignum.dll, and then metaheap.dll and then kernel32.dll and then... hey, wait, kernel32.dll's already in the loader's database so we can stop. After processing the static imports, it appends the new entries to the global initialization list and keeps track of the new entries. To wit, the global init-order list looks like:

ntdll.dll
kernel32.dll
msvcrt.dll
metaheap.dll
bignum.dll
calclogic.dll

and the init list that it has to process before LoadLibrary() returns is:

metaheap.dll
bignum.dll
calclogic.dll

No suprises yet, eh?

Now let's add the first twist. There are cycles in the dependency graphs of many DLLs. Why? Well, because they are. Two teams or two companies were independently working on something which maybe was conceptually part of the same thing but they had to build, test and deliver the two things independently. Component granularity is suprisingly hard to get right and very rarely has to do with what's best for the components. Instead it's a combination of what's best for the teams (teams don't like to have multiple DLLs and teams want autonomy w.r.t. a single DLL so that their testers can feel comfortable about what it means to test the component) and what's best for the perf team (one DLL per function would destroy system performance; in a big system, if 10% of the teams "just add one more DLL" for each release, you end up with dozens and dozens over time for no apparent reason other than it was easier than modifying an existing DLL).

What does the loader do when it finds these? not much. I already described the algorithm above when the dynamic load case reached kernel32 again. (It's a little more complicated because of the interaction of refcounting and cycles but I'll make a separate post on that.)

If A depends on B and B depends on A, the initialization order depends on which one you found first. If you loaded A first, it would be added to the tables and then B would be found and added to the loader's tables. Then when walking B's imports, it would find A again and say that it's over and done with. Thus if you loaded A, B would be initialized first since it would appear to be deeper in the graph than A. Similarly loading B first will result in A initialized first.

The implementation is linear/sequential. Therefore even the order of the imports in your static import tables matters. I can't guarantee which order is used but assume you have DLL c.dll which links against both a.dll and b.dll. If a.dll happens to be in the import tables first (assuming that the imports are walked in order), it will be added first and then b would be discovered and we'd decide that b was deeper. If the linker for some reason reverses the order of the static imports, you'll see the opposite.

Now let's say you're ccalc.exe and you link against c.dll. The init order might go B -> A -> C. But now let's say that ccalc decides to link against b.dll itself. Now maybe the init order is A -> C -> B!

This leads to the first hazards in DLL initialization order:

The way that cycles are resolved into an initialization order are stable for any given graph but if the graph changes for some reason, the initialization order may change.

If A calls into B during its DLL_PROCESS_ATTACH, this may have worked for years and years but suddenly because of either the addition or removal of an import by some other DLL in the graph can break the initialization order.

My team debugged so many of these during Windows XP it wasn't funny. Sure we were the obvious targets, who are those crazy folks over there changing the DLL loader?!? Are they mad? They must be the cause that my code which has worked for 10+ years is suddenly broken! But we got pretty good at recognizing the defective patterns. (The changes themselves weren't defective - anyone adding or heavens forbid actually reducing/removing dependencies would cause these effects.)

I even have recommendations about what (not!) to do during DLL initialization to avoid these problems yourself. They'll be at the end of the series and I can say right now that I don't think you're going to like them one bit.

How the NT Loader works

2005-06-18T09:27:00Z

My team maintained the NT loader (the component that loads DLLs) for about a year or so during Windows XP as we were adding the isolated application features to it so we got quite an interesting perspective on this lovely little piece of technology. Warning to people who find themselves wanting to innovate in technology which has basically been left dormant and untouched for over a decade: be sure you have plenty of time to deal with the anthills you knock over!

We don't own it any more (not sure if it's a blessing or a curse...) but it sure was interesting and enlightening; especially in the tradeoffs of application compatibility, robustness and reliability.

You might notice that the docs for DllMain have grown a lot over the past few years. I like to think that my team's involvement here had a lot to do with it because DLL load order etc. was always a vaguely understood and arcane topic. There were always vague warnings about not doing too much in DLL_PROCESS_ATTACH but nobody could really describe the situation except for a number of anecdotes they had had in the past when somehow mysteriously load orders changed and they were broken during either initialization or shutdown.

I'll take a break from where I'm headed on the reliability front and walk through a summary of the issues which I recently sent to the internal win32 programming email alias. Hopefully I'll fix the incomplete sentances and bad grammar this time.

I'll make a separate post with the beginning - a basic rundown of how things work today. As usual, do not consider this in any way shape or form a contract. One of the reasons that this isn't documented fully is that people have wanted to change/fix it for years and years now. On the other hand, maintaining compatibility with the current behavior is going to constrain the implementation so much that either (a) it won't change after all or (b) the change will have to be compatible with the effects of anything I'm describing here anyways.

You will see aspects of my reliability/robustness series come up here. You'll laugh, you'll cry, you'll see local innocuous bugs in DLL initialization or uninitialization affect the entire process's reliability.

Enough about in-memory models and transactions for now

2005-06-01T07:18:00Z

I want to follow up on this topic of transactional behavior in memory but to motivate it I'm going to have to further discuss my other topics more about invariant restoration and (eventually) failure handling.

The main point is this: there are potentially better ways to solve this overarching problem but there isn't a lot of coherent support for having a set of components which play together well. You can yourself take on this "transactional" mantra but unless there's deep support for it (possibly integrating with a "real" transactional facility to enable interaction with (rollback/commit of) persistest side effects), you're generally stuck reinventing everything.

I still think it's interesting to take a moment and compare and contrast the reliability of a system which worked in light of transaction support like we've been discussing vs. manual/explicit rollback code. For extra points, what's the difference between the rollback proposed here and use of C++ destructors.

Transactions and in-memory data (part 3 of n)

2005-05-18T09:24:00Z

Last time I laid out a little framework for transactional rollback. It clearly is not sufficient for a real honest-to-goodness persistent transaction but if you can tolerate every ESE failing (due to allocating the rollback log entry) it's pretty compelling. Pretty much every function can be transactional if it only works with data structures/algorithms which could support this metaphor. It might look something like...

int do_work(collection_t *collection, int x, int y, int z) {
   rollback_record_t *txn = NULL;
   int err;
   if ((err = collection_insert(&txn, collection, x))) {
      do_rollback(txn);
      return err;
   }
   if ((err = collection_remove(&txn, collection, y))) {
      do_rollback(txn);
      return err;
   }
   if ((err = collection_do_something_else(&txn, collection, z))) {
      do_rollback(txn);
      return err;
   }
   free_rollback(txn);
   return 0;
}

Hey, that's kinda cool. Pretty easy to write a transactional function, eh? But wait there's more. With this metaphor it's also easy to be a good transactional citizen!

int do_work(rollback_record_t **parent_txn, collection_t *collection, int x, int y, int z) {
   rollback_record_t *txn = NULL;
   int err;
   if ((err = collection_insert(&txn, collection, x))) {
      do_rollback(txn);
      return err;
   }
   if ((err = collection_remove(&txn, collection, y))) {
      do_rollback(txn);
      return err;
   }
   if ((err = collection_do_something_else(&txn, collection, z))) {
      do_rollback(txn);
      return err;
   }
   merge_rollback(txn, parent_txn);
   return 0;
}

Hey, woah maybe we're on to something!

Hmm.. it's going to be hard to use other libraries... what if I don't really need this level of guarantee? What if people point at the code and say it's weird? I guess social acceptability is as important as reliability and correctness...

Transactions and in-memory data (part 2 of n)

2005-05-17T10:04:00Z

Buffering the opertations wasn't particularly successful.

Let's look at maintaining a rollback log.

Seems pretty simple. You can do something like:

typedef void (*rollback_function_ptr_t)(void *context);
typedef struct _rollback_record {
   rollback_function_ptr_t rollbackFunction;
   struct _rollback_record *next;
} rollback_record_t;

void do_rollback(rollback_record_t *head) {
   while (head != NULL) {
      rollback_record_t *next = head->next;
      (*head->rollbackFunction)(head + 1);
      free(head);
      head = next;
   }
}

That's pretty simple, eh? Since rollbacks probably have to be done in reverse order of changes, you have to maintain the list with a stack discipline (always adding to the head). Whenever you're going to do anything which mutates global in-memory state, you first allocate a rollback record plus space for your own data, fill it in and then put it on the head of the list.

Sounds good at one level, but simultaneously it totally breaks the model of folks like STL who were trying to do the right thing by providing a few functions like std::map::erase() which do not fail. Now these destructive actions have to be able to fail since they can allocate a rollback record which can fail.

Next time I'll go into this model a little more and point out some of its problems but since I hadn't written since Thursday I wanted to get the start of this out at least.