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

First chance exceptions are normal - these are displayed whenever an exception is thrown, whether it was handled or not. They exist so you can go into your code and find out why they are thrown.

However, if the exception has been handled, there is no problem and execution will resume.

If the exception was not handled, a second chance exception will be caught by the debugger and execution will halt.

This is normal and shouldn't be of concern. You can always hide them - see this question and answers for more details.

In regards to the actual exceptions - there is some code (third party or your own) that is trying to access a ttf in the mentioned directory, this cannot be found, hence the exception (which was handled, so no problem).

The other exceptions are due to create a non existing CultureInfo (ug) - perhaps this is supposed to be uk? Check configuration and code for this.

These values may be configured in the registry.

Answer 2

It is very unlikely to be the shovel-ware on your machine. These DLLs need to inject themselves also into non-managed programs, they have to be written in a language that doesn't depend on the CLR, like C or C++. And accordingly cannot generate managed exceptions.

These exceptions look like machine configuration problems to me. Junk in your registry. The bad culture name (sounds like "us" got corrupted to "ug") generates three of them, the font is probably listed in the registry but missing from the disk.

Short from a OS reinstall, you could possibly diagnose this by using both ProcMon and the debugger. Use Debug + Exceptions, Thrown checkbox to force the debugger to stop on the first-chance exception. When it hits, switch to ProcMon, the registry key or file should be visible very near the end of the trace.

Answer 3

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.