Building a Silverlight 5 app that runs in the browser but getting some nagging errors that are showing up in JavaScript, they aren't being caught by Visual Studio for some reason when the debugger is attached. I've done the simple stuff (create VS SL 5 project w/ a web project). When I'm debugging, the errors are showing up in the browser via JS... not in Visual Studio.
I can set breakpoints and walk through them, but when an unhandled exception happens, SL is just bubbling it up through the page (as expected), but VS isn't catching it.
I've verified that VS is attached to the IE process and the Type=Silverlight. Right now the bug I'm fighting with is the nagging 4004 error code (category=managedruntimeerror) with the message of "system.argumentexception: value does not fall within the expected range" but I can't find where that is happening w/o a stack more detail. All I get is the "Visual Studio JIT debugger" that looks very much like this http://www.scottleckie.com/2010/04/code-4004-unhandled-error-in-silverlight-application/ but his solution isn't working for me...
Look in your App.xaml.cs and you will find a handler called Application_UnhandledException.
There should be some code similar to this:
Deployment.Current.Dispatcher.BeginInvoke(delegate
{
ReportErrorToDOM(e);
});
Replace it with your custom error handling method. The ReporErrorToDOM is what triggers the javascript error in your browser.
If there isn't one you need to set one up:
public App()
{
this.UnhandledException += this.Application_UnhandledException;
...
}
private void Application_UnhandledException(object sender, ApplicationUnhandledExceptionEventArgs e)
{
// Handle exception here
...
// Don't forget this !
e.Handled = true;
}
Related
This is Windows Forms application.
As in title, I can't debug Task in Visual Studio 2015. If I will check breakpoint at line var a = costam(); it will be hit, but if then I will press step into, or continue, execution will not be continued. This works fine in Console Application. For now i checked, that error appears when I'am trying to run my own method in Task, or if I'am invoking something.
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
Task.Run(() =>
{
var a = costam();
});
}
string costam()
{
return "s";
}
}
I would suggest changing the settings to break on any exception in the debug menu, not only uncaught ones. This option is called breaking when the exception is "thrown". Unfortunately the 2015 exceptions menu I'm not familiar with so I can't help you out with that.
There are certain exceptions that are caught and suppressed behind the scenes, especially with WinForms--constructors / load events are particularly shielded. It's likely that it doesn't like spawning a new thread in the UI thread which is why it's throwing an exception in your WinForms application but not the console application. This also explains why "stepping in" "doesn't work"--it steps in but the exception means the next breakpoint isn't hit.
Update 1 to VS2015 seems to solve this issue.
There's no error message and no indication why it is not displaying the window. The app initialises App.xaml.cs: App() {} and I can step through the App.xaml file. It gets the startup uri and then... silence. No output in the Output window and no unhandled exception and no window, I can't find where to put a breakpoint to debug as it isn't hitting the start of MainWindow.xaml.cs.
Really confused.
This was working 20m ago.
In that time all I did was add Windows.Office.Interop.Outlook reference. I removed the reference and rebuilt but still the same. Would that cause this problem? Has anyone seen this before? Google isn't helping!
EDIT :
App.xaml.cs:
public App()
{
using (var dbContext = new DBEntities())
{
if (!db.Exists())
{
try
{
db.Database.Create();
MessageBox.Show("Database created"); // this is the problem!!
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
}
}
}
}
I've added App.xaml.cs, I found that the problem was using a MessageBox to give info (this is still in development!). I'd been meaning to get rid of it and eventually did and my problem went away. This meant I could find relevent Goolge results:
MSDN query and answer for exactly my problem
I will be adding an 'loading window' in between app load and main window load eventually in which I will be able to feedback information using Bindings etc.
Fixed error by removing the MessageBox.Show(..) call. The selected answer from the MSDN URL given in the question states:
"I performed a test based on your description, the applicationi stop at the method : USER32!GetMessageW+0x33, calling USER32!NtUserGetMessage"
I assume this is what was occurring in my case, although I didn't test it.
What happens if you create a new window and set that as the StartupUri?
You also might want to create a new project and make sure that the namespaces referenced in the App.xaml in your existing app haven't somehow been inadvertently edited.
I want to circunscribe this question to the specific context of WPF aplications.
The accepted answer says
"You should only to catch exceptions that you can actually do something about"
and also
"Note that if you're simply trying to catch any unhandled exceptions that might occur for the purposes of logging or error reporting, you should be using the AppDomain.UnhandledException event"
Well, all would be good and well EXCEPT (pun intended) that I had a very serious problem while deploying a WPF application which would crash right at application startup, with the dreaded IOException error in PresentationFramework.
I tried the Application.Current.DispatcherUnhandledException, but the crash apparently happended outside its grasp. I tried Windbg but the error messages were still elusive.
Then I followed advice from this post (changing app.xaml Build Action property from "Application Definition" to "Page" and putting Main() function inside App.xaml.cs itself), putting a try/catch with a MessageBox (it could be a logging call, whatever), and the message displayed immediately led me to the solution.
So the question is:
Considering WPF has its own esoterical bugs, is there any actual problem in putting Main() function body inside a try/catch?
Here is my current code:
public partial class App : System.Windows.Application {
/// <summary>
/// Application Entry Point.
/// </summary>
[System.STAThreadAttribute()]
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public static void Main() {
try {
var v3d = new App();
v3d.InitializeComponent();
var shellview = new ShellView();
v3d.Run(shellview);
} catch (Exception e) {
MessageBox.Show(e.ToString());
}
}
And for the record, I was getting "Cannot locate resource 'app.xaml'" caused by some culture mismatch, the problem happened in only one of two similar machines apparently because one OS (Win7) is English and other is Portuguese. I solved it with this answer.
I have a C++ application in which I'm trying to show a WPF form (named WSWindow), specifically one that inherits from the System.Windows.Window class so that I can get the window handle using the WindowInteropHelper class.
My problem is that whenever I make the call to the method below, the application crashes.
public IntPtr GetHWND()
{
if (ivWindow == null)
{
ivWindow = new WSWindow();
ivWindow.WindowStartupLocation = WindowStartupLocation.Manual;
ivWindow.Show();
}
IntPtr handle = new WindowInteropHelper(ivWindow).Handle;
return handle;
}
I believe the WSWindow constructor is causing the crash. On the C# side of things there's a WSService class that calls the WSWindow constructor, and if I put the WSWindow constructor in the WSService constructor, the C++ app crashes on calling the WSService constructor (something that works fine when the WSService constructor does not contain the WSWindow constructor). Also, in addition to calling the above method, I've tried the following in the C++ app:
WSWindow^ w = gcnew WSWindow();
and there are log lines immediately after this line that don't get written to the log file.
In the WSWindow contructor, there's a call to InitializeComponents, which is generated code in the WSWindow.g.cs file:
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public void InitializeComponent() {
if (_contentLoaded) {
return;
}
_contentLoaded = true;
System.Uri resourceLocater = new System.Uri("/Project_Name;component/wswindow.xaml", System.UriKind.Relative);
#line 1 "..\..\WSWindow.xaml"
System.Windows.Application.LoadComponent(this, resourceLocater);
#line default
#line hidden
}
At first I thought maybe the call to LoadComponent was failing because the uri couldn't be resolved, but I added a log line in the WSWindow constructor before the call to InitializeComponent() which gets written when the WSWindow is created from a Windows Forms test app, but not when the WSWindow is created by a call from the C++ app, so it seems like nothing in the WSWindow constructor even gets executed, it just crashes right away.
There's no problem with references that I can tell; I've written a couple test methods, one that returns an int, one a simple custom Window object with width/height members and successfully called both from the C++ app.
I've also successfully retrieved the handle to the WSWindow when it is compiled as a WPF app and run before launching the C++ app, but I need to be able to create the WSWindow from a call within the C++ app.
I've spent days on this problem trying to figure out why the crash is occurring with no luck. I'm hoping someone that reads this knows something about WPF that could be causing this issue, or a known issue between C++/CLI and WPF controls. I'm totally out of ideas.
Additional info: When I start the C++ app and attach VS to the process, nothing shows up in the call stack (a separate problem for me to work on), but I noticed a couple exceptions that look like they might be related:
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: HRException at memory location 0x06e6b158..
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: HRException at memory location 0x06e6b608..
First-chance exception at 0x75a8b9bc (KernelBase.dll) in MM.EXE: Microsoft C++ exception: [rethrow] at memory location 0x00000000..
The solution was that I needed to mark the thread making the call to create/show the WPF Window with the [STAThread] attribute.
I have a SL OOB app (it only runs OOB) and was wondering about the ReportErrorToDOM code in the app.xaml.css:
From what I understand, HtmlPage wont work in OOB as there is no DOM/HTML? Is that why this code is wrapped in a TryCatch block? (this is the default for a new SL4 app).
To get my OOB app to display unhandled errors to the UI, should I judt replace the HTMLPage with a MessageBox.Show?
I can't find anything on Google about this, opinions appreciated...
private void ReportErrorToDOM(ApplicationUnhandledExceptionEventArgs e)
{
try
{
string errorMsg = e.ExceptionObject.Message + e.ExceptionObject.StackTrace;
errorMsg = errorMsg.Replace('"', '\'').Replace("\r\n", #"\n");
System.Windows.Browser.HtmlPage.Window.Eval("throw new Error(\"Unhandled Error in Silverlight Application " + errorMsg + "\");");
}
catch (Exception)
{
}
}
As an initial starting position yes you should replace the code with code that uses MessageBox.Show to display the error.
What is appropriate for a production quality release will depend on the type of application. Strictly speaking if your application has encountered an unhandled exception it would be in an indeterminate state so a message box and/or the replacing of the root visual might make sense.
If its a game then simply swallowing the error might even be appropriate or just noting it in some log.
Take a look at the Silverlight Navigation Application template in VS - it uses a ChildWindow to show errors, and this works OOB as well. You could just generate a dummy project from this template and copy/paste most of the code over to your app to get going quickly, then tweak the UI to suit your needs.