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?
Related
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.
I've created a number of Silverlight applications used in various MS systems, from CRM 2011 to SharePoint.
The applications aren't perfect, and I'll be the first to admit it, and sometimes things go wrong. All my applications already display what went wrong:
private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
{
(...)
UIDispatcher.Invoke(() => ARP.DynamicsCRM2011.Silverlight.GlobalHelper.Controls.MessageWindow.ShowMessage(e.ExceptionObject.Message));
(...)
}
HOWEVER, almost always, the end user will NOT have the Silverlight developer SDK installed, and will, subsequently, only receive a generic "Debugging Resource strings are unavailable" message.
The message will usually contain some very basic form of the exception that occurred, but it's hardly ideal. I also know I'm missing a proper stack trace from the error (this is, of course, easy to fix).
I'm thinking of rewriting that exception handling code to show a generic "something went wrong, please try again message", and an extra "show log" button to display all the exception information along with the stack trace.
My question, however, is... how should I deal with those missing resource strings? If something goes wrong, I would like to get as much information as possible, but I cannot require my users to all install developer SDKs.
What's the best course of action in this situation?
I don't know if this is an option for you but you could log those info in database or in a local file that you could retrieve in case of error. But I don't kow if this is something you can consider (ex: application are for your compagnie but not public,etc.)
We have a windows form application running across different customers, when they get errors we log into a database & using that stack information that is logged, we correct the issue.
However there are issues that occur only in production, the stack shows for example
CalculateTotals(method name) :NullReferenceException: Object reference not set to instance of an object.
The CalculateTotals is a method name, that has lots of sub-method calls & more lines, i am not able to get the exact line # of the code where it fails.
My application's PDB file is not sent to customers (when they do installation),
how do i keep a copy of that .PDB file (may be in a remote location and
not make it part of installation) and use that to
debug the errors & get the exact line?
You can include the pdb-files in release if you want to, but you can also use IntelliTrace to debug data from production in Visual Studio.
In short, IntelliTrace:
IntelliTrace plays a role similar to that of a black box in a plane. It keeps track of important points in your programs execution and allow you to play back what happened at those points at a later time.
Have a look at these blog posts:
Running IntelliTrace on Applications in Production
IntelliTrace - what and how.
And of course, you can search the web and find more about IntelliTrace.
You will only get line number info in the exception's stack trace when the CLR can find the PDB file at runtime. You are making this difficult by wanting to do this from a remote location but it is not impossible. The underlying API that the CLR uses is DIA (Debug Interface Access) which in turn uses the Debug API.
You'd have to setup the machine the same way you'd setup a debug session to have the debugger use a symbol server. Requirements are that you first setup a symbol server that can be accessed across the Internet, similar to the Microsoft Symbol Server. Then set the _NT_SYMBOL_PATH environment to reference that server. The core MSDN Library page that describes this is here. Beware that this is not easy to troubleshoot if it doesn't work.
An entirely different approach is that you create a minidump from the crashed process. You'll need to pinvoke MiniDumpWriteDump(). Beware that a good minidump for a .NET process is not very mini, you'll need the plumbing to have enough storage and somehow get it to your machine.
Yes, I have Googled this and found absolutely nothing useful.
I want to use LAME.DLL (NOT LAME.EXE) from C# to turn a WAV into an MP3.
The two CodeProject examples (MP3compressor and Aumpel) that every screen scraping help forum points to are broken. In the EncodeChunk() function, it throws an MSCORLIB engine execution exception right where it calls down to the pointer overload of beEncodeChunk(). The error message almost immediately crashes the VS2005 debugger and I get an uncaught exception running it regularly. Running in debug or release mode doesn't change anything, nor does allowing unsafe code.
The Aumpel CodeProject page says source code updates can be found on his site, but this is untrue as pretty much everything but the Paypal link is missing or broken and there's no telling if purchasing his program grants access to said source code or not.
Has anyone seen any working alternatives to using an ugly command line call or porting the LAME source to C#?
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.