Develop Reference

When does Silverlight show "Debugging resource strings are unavailable." message?

I have had a few reports of a message box showing up on application launch with the following contents:
[Arg_NullReferenceException]
Arguments:
Debugging resource strings are unavailable. Often the key and arguments provide
sufficient information to diagnose the problem. See http://go.microsoft...
I understand the link provided gives me the exception detail, and I obviously have a null ref somewhere. I haven't been able to reproduce this, so I am trying to find where this message is being thrown and hopefully add some error handling.
Is this specific message box something baked into Silverlight, or is it following whatever exception handling is in place when such an exception occurs? In the app constructor, I have
this.UnhandledException += this.Application_UnhandledException;
which is:
private void Application_UnhandledException(object sender,
ApplicationUnhandledExceptionEventArgs e)
{
MessageBox.Show(e.ExceptionObject.Message + "\n" + e.ExceptionObject.StackTrace);
}
So it looks like this message box is not coming from the Application_UnhandledException or it would have a message, newline, then a stack trace. So now my two options for how this message box is being generated are: 1) Silverlight is doing it in the background, or 2) this is coming from an existing catch block, although I have found none that would display in this way.
I'm doing offline caching of XAPs in Isolated Storage using OfflineCatalog, which involves some asynchronous WebClient downloads and fall-backs to Isolated Storage when requests fail. It makes sense that a null ref might be happening somewhere in this process.
To summarize, I'm wanting to add some exception handling for this Null Reference, but cannot reproduce it locally, and cannot find where it may be coming from. If this is coming from an unhandled exception, why does it not display the message and stack trace as specified?

The error message occurs if the machine does not have Silverlight SDK installed normally.
To debug similar browser side exceptions, it is common practice to use Visual Studio. If you cannot use VS, simply use WinDbg to attach to the browser process.

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

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.

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.
Create a new console app.
Add a reference to sysglobal.
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();
Build.
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.

I had the same problem.
It disappear after I did:
Clear the WPF font cache and restarted Visual Studio.
Clear the cache: http://support.microsoft.com/kb/937135
Éric

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.

With leads from the above answers I was able to solve this issue by deleting the font "Microsoft Uighur Regular"

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.

How to prepopulate an Outlook MailItem and avoiding a com Exception from the object model guard

I work for a company that develops a CRM tool and offers integration with MS Office(2003 & 2007) from windows XP to 7. (I'm working using Win7)
My task is to call an Outlook instance (using C#) from this CRM tool when the user wants to send an email and prepopulate with data of the CRM tool (email, recipient, etc..)
All of this already works just fine.
The problem I'm having is that Outlook's "object model guard" is throwing com Exception
(Operation aborted (Exception from HRESULT: 0x80004004 (E_ABORT)))
the moment I try to read a protected value from the mailItem (such as mail.bodyHTML).
Example Snippet:
using MSOutlook = Microsoft.Office.Interop.Outlook;
//untrusted Instance
_outlook = new MSOutlook.Application();
MSOutlook.MailItem mail = (MSOutlook.MailItem)_outlook.CreateItem(MSOutlook.OlItemType.olMailItem);
//this where the Exception occurs
string outlookStdHTMLBody = mail.HTMLBody;
I've done quite a bit of reading and know that my Outlook Instance (derived by using new Application) is considered untrusted and therefore the "omg" kicks in.
I do have a workaround for development:
I'm running VS2010 as Administrator and if I run Outlook as Administrator as well - all is good. I suppose this is due to them having the same integrity levels(high) and the UAC(?) is not complaining. But that just ain't the way to go for deployment.
Now the question is:
Is there a way to obtain a trusted instance of Outlook so that I can avoid this exception?
I've already read that when developing an Office Add-In using VSTO one can obtain a trusted Instance from the OnComplete event and/or using "ThisAddin"
But I "merely" want to start an outlook instance and preopulate it, and do not want to develop an Add-In since this is not the requirement.
And to make it clear - I have no problem with pop ups informing the user that outlook is being accessed - I just want to get rid of the exception!
So how can I get around this problem using code?
Any help is highly appreciated!
Thomas

Take a look at Dimitry's Redemption Lib, It was designed to do exacly this.

Well,
I've already spent way too much time and energy on this question so I think I came up with a pragmatic workaround for my particular case - but no real solution!
The problem is apparently due to the programms running at different integrity levels (Outlook = medium, VS2010 = admin or high). Office runs by default on a medium level and so will my future application once deployed. So there shouldn't be any trouble, since if the CRM and Outlook run at the same level, there's no problem.
For development I just let em both run on high, or medium (starting my compiled files from the debug folder).
In any other case a Messagebox warning is shown informing the user of the different integrity levels that cause an exception and prevent access.
At the code level, when I try to read any (by Outlook) prepolutated, protected properties and the object model guard raises the exception, I just catch it and use default values instead.
Why I had to read them in first place is currently beyond me - but so were the specs which were handed to me.
Anyway thanks for reading and if I ever come up with a solution I'll be sure to psot it - until then keep in mind that a pragmatic solution is better then none!
Happy Father's Day everyone!

"Errors During Preprocessing" is non-zero in ASP.NET perfmon counters

While testing an ASP.NET application with perfmon, we find that the following field is non-zero:
ASP.NET Apps v2.0.50727 > Errors During Preprocessing
Documentation says that this field is "The number of errors that occurred during parsing, excluding compilation and run-time errors."
However, I have not been able to track down why this is happening.
Any clues on where these actual preprocessing errors are logged? Or how to enable logging so we can fix these errors?

One thing I would try is to precompile your application from the command line using aspnet_compiler. e.g. from a VS command window, try something like:
aspnet_compiler -v / -p c:\PathToYourAppRoot
At runtime, there is some fallback behavior which may mask some errors. But when running aspnet_compiler, it should be catching and displaying any error that it encounters.
If that doesn't help, another thing you can try to isolate the issue is figure out after what specific http request the counter goes up. e.g. does it go up as soon as you send the first request, or only after hitting specific URLs?

Check your event viewer. They should be showing up there. You may also want to look at the link below for info on how to send the event logs to other places (db, email, etc...)
http://www.asp.net/(S(sf10gzjodvrpce55el2p5cnk))/learn/hosting/tutorial-13-cs.aspx

VB control crashes my app

I am using this - otherwise excellent - vb tab control in one of my c# apps. When the app using it is installed on another machine, Windows tells the user in its usual friendly and descriptive manner that "The application encountered a problem and needs to close". I guess the control has some hidden vb-related dependency, but what can that be?
Any ideas guys?

Since the tab control appears to be managed code as well, your 'crash' is most likely an unhandled .NET exception.
Looking at the error details (by expanding the error dialog using the button provided for that purpose...) should give you the exception message, which should give you an idea of what's going on. If it's a missing dependency DLL, the name should be included in the message.
To get the full exception, including the stack trace, one of the following should work:
Least effort: in the first line of your own managed code, add an unhandled exception handler which shows the full exception in a message box or logs it to a file prior to rethrowing it
Medium effort: attach a debugger to the process on the client machine. If it's on your local network, setting up remote debugging should be trivial, and should also allow you to debug exceptions that occur prior to your first line of code executing (which may very well be the case if the error is binding-related...)
Most effort: obtain the crash dump file from the client machine, and look at the managed exception using Windbg and the SOS debugging extensions. Getting productive with the tools involved will take some time, but on the plus side will teach you valuable debug ninja skills that will allow you to tackle pretty much any 'mysterious crash'...
BTW, all standard 'VB dependencies' are part of the default .NET Framework install, so that's not your problem -- only the exact exception (and possibly stack trace) will tell you what's going on.

Click the 'What data does this error report contain?' button and there will be more descriptive info. (i.e. type of the thrown exception, module etc.).
For additional info see Dr. Watson vs. CLR.

Is the dll containing the control distributed with your app? Perhaps you have a dependancy in the GAC thay you are missing?