Locating the source of managed exceptions that aren't coming directly from my code?

Question

I apologize in advance if this is really a Super User question... I just wasn't sure, but this seems more on the dev. side than on the tech support side. :)

This isn't necessarily a problem, but it does actually drive me totally bonkers on my system. It also only happens on my computer.

When I launch any application, even a blank WPF application, I see four exceptions:

A first chance exception of type 'System.IO.DirectoryNotFoundException' occurred in PresentationCore.dll
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
A first chance exception of type 'System.InvalidOperationException' occurred in PresentationCore.dll

To figure out where these are coming from, I then set VS2008 to break on any thrown CLR exceptions, and here is the information:

Exception #1:
Cannot find a part of the path 'D:\Dell\Reader2.0\SPLASH.SYS\fonts\AscenderUni.ttf'.

Exception #2:
Culture name 'ug' is not supported.
Parameter name: name

Exception #3:
Culture name 'ug' is not supported.
Parameter name: name

Exception #4:
There is no registered CultureInfo with the IetfLanguageTag 'ug'.

I've poked through Process Monitor and Process Explorer. Process Monitor shows that my application is doing a RegQueryValue, which I'm certainly not responsible for... but some DLL (presumably from Dell crapware) is getting loaded by my process and is reading this regkey. I then looked at Process Explorer, hoping to see which DLLs my application is loading, but can't find that info. I then tried PrcView and saw the modules my application was loading.

I was surprised to see how many other modules were getting loaded, but I didn't see anything Dell related. I'm also wondering how it is possible that a Norton Internet Security DLL got loaded into my process, but I assume that's intended and something special that Norton does to ensure that a process is safe to execute.

What else can I do to identify and remove where these exceptions are coming from?

UPDATE

Not sure if it's confusing what I'm getting at here. This exception is raised in a DLL that my application loads for some reason (I don't reference anything Dell-related from my project). I've now uninstalled that app, and I still get the stupid exceptions. It's all technically fine because the exception is handled somewhere, presumably within that DLL, but I'm just annoyed because four extra messages (actually 8, since I have to close two dialogs per exception) pop up when I run my application. Call me lazy, but I never asked this damn DLL to load in the first place. :)

Perhaps now it's time to use msconfig to start disabling some Dell services. I'll play with that later when I actually have free time.

Answer 1

No file corruption. As I've been trying to hunt this one down for a while, I figured out what happened. Somewhere along the way, a font was installed with Uighur culture, which is, apparently a Turkish/Chinese culture (as best as I can tell), and their CultureInfo tag? "ug". When the fonts were cached, the system was attempting to load the Uighur culture. Sadly, my installation of Windows seems to be conspicuously missing this culture in Windows. Knowing that I won't be using the culture on my machine anytime soon, I followed the directions on MSDN to create and install a new culture.

Though the error won't hurt anything major. It is just a first chance exception, after all, it was annoying the crap out of me. So here's what I did.

1. Create a new console app.
2. Add a reference to sysglobal.

3. Add the following code:

       var culture = new CultureAndRegionInfoBuilder("ug", CultureAndRegionModifiers.None);
       var ci = new CultureInfo("en-US");
       var ri = new RegionInfo("US");
       culture.LoadDataFromCultureInfo(ci);
       culture.LoadDataFromRegionInfo(ri);
       culture.Register();
   

4. Build.

5. From Windows Explorer (you need admin privileges to do this), run the compiled executable as administrator.

If all goes well, there should now be a file in C:\windows\Globalization called "ug.nlp".

You shouldn't receive that message again.