The Friendly Coder

On software development and technology

Wacky Windows App Initialization Problem

I recently spent several hours debugging a very strange startup problem with an application I was developing, and the root cause was so wacky I just had to blog about it.

The Symptom

For starters, when I tried running this particular application, I would get the following dialog appearing before any of the application’s UI was displayed:

error_dlg

A quick Google search for the provided error code, 0xc00000ba, didn’t reveal anything useful. It was pretty obvious to me the problem lied somewhere in the applications initialization process, and I suspected the problem was during the pre-execution phase when the runtime dependencies were being loaded into memory. This was confirmed with a well-placed breakpoint in the applications main() function that was never hit.

The Analysis

I have several tools in my toolbelt, as all good developers do, for just such occassions – Dependency Walker, Process Monitor, the Windows event viewer, etc. Dependency Walker successfully loaded all dependencies, so I knew I wasn’t missing a runtime library and that the application wasn’t referencing an incompatible DLL with the wrong platform configuration or anything like that. There were no entries in the Windows event viewer suggesting that the problem might have been related to a SxS assembly being setup incorrectly. I even gave my copy of the application to other developers with similar desktop configurations and it ran successfully for them, so I knew the problem must be related to my local machine somehow.

So that led me to use the lovely Process Monitor tool from the SysInternals application suite from Microsoft. When I analysed the startup behavior of the application I discovered the following odd looking error just before the popup dialog appeared:

proc_mon

What! Windows was trying to load a DLL, bag.dll in this case, from a Windows system folder and it was being reported as a directory? That couldn’t be right – could it? So I immediately cracked open my shell and navigated to the c:\Windows\SysWOW64 folder and sure enough – there were dozens of folders under there with the same name as DLLs used by my application. Don’t believe me? See for yourself:

dir_list

The Fix

Being the adventurous type I took the liberty of taking all of the sub-folders under the SysWOW64 folder that were named after DLLs and I moved them to my desktop and… PRESTO! My application started working!

I examined the contents of the folders I backed up to my desktop and I noticed that most, if not all, of these strangely named folders did in fact contain copies of the actual DLLs the folders were named after. Another odd coincidence was that all of these folders had the exact same creation date.

Unfortunately I was unable isolate the originating source of these seemingly magical folders. I know I didn’t create them intentionally, so it must have been something on the system that created them. I was unable to locate any user-defined process, application or script on my machine that could have created them so I suspect some rogue Windows process or maybe a bug with some portion of the operating system must be to blame, however I have been unable to find any reports on the typical forums describing any behavior even remotely similar to this. I suspect that if such a problem were to happen to the typical PC user or even a typical developer, they would most likely just re-format and re-install the OS and be done with it.

Hopefully my findings here help at least one person out there avoid a re-install at some point. If so, I would love to hear from you in the comments below! Also, if anyone out there has any insight on how such folders may have been generated in the first place I would love to hear from you as well.

Leave a Reply