I've been developing an app for Windows 8 and can test Suspend, Resume, Shutdown, etc. from Visual Studio 2012. However, when I test the app on a Microsoft Surface, there is one other state I can't seem to simulate.
When an app is open and you leave the Surface untouched for a bit, the screen will dim and then eventually shut-off. If I wait long enough, maybe 1 or 2 minutes, and hit the start button, it will take me to the Lock Screen, where I can sign in. Once I sign in, it will show my app where I left it. However, after 1 second, it crashes immediately, and the Surface takes me back to the Start Screen.
I cannot simulate this using Visual Studio and the Simulator. Suspending/Resuming using Debug Location does not recreate this.
I looked at the event log on the Surface and found that my app was crashing with the following:
The process was terminated due to an unhandled exception.
Exception Info: System.Exception Stack: at
System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at
System.Threading.WinRTSynchronizationContext+Invoker.<InvokeCore>b__0(System.Object) at
System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object) at
System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at
System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at
System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() at System.Threading.ThreadPoolWorkQueue.Dispatch() at
System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
I have no clue how to find this. I am handling all unhandled exceptions with a standard message box, but it's not showing up. We've been very good at avoiding "async void" and making sure everything has "async Task" and awaited properly. So, I'm a bit stuck. I can't find where this is happening.
Anyone know how I can simulate this, or at least make the Event Log more verbose?
It sounds to me like you have everything you need to test your scenario. But you may not be aware that you can remotely debug your app on a Surface just like it was running locally. As a result, you can proceed through your use case and let Visual Studio catch the exception:
It's easy. Here's a walkthrough: http://timheuer.com/blog/archive/2012/10/26/remote-debugging-windows-store-apps-on-surface-arm-devices.aspx
Ok I figured it out.
There is an issue with the MediaElement control and volume. When the app is reactivated as I explain above, we get notified that the volume has changed. But for some reason, if we try to manipulate MediaElement.Volume when the app reactivates, it throws an exception. This exception does not have a message, just some strange hex number.
This only happens on the tablet, and it's very hard to detect. Essentially, for all of you who play media files, you should try/catch it like this:
try
{
myMediaElement.Volume = .3;
}
catch (Exception ex)
{
// I don't really know what to do here.
// but at least my app doesn't crash anymore :)
}
Anyway, thank you #JerryNixon and #chuex for helping out.
Related
I develop a Windows Phone 8.1 program using winRT and have an error which is not caught by VS. The only output line I get is "The program 'MyProgram.exe' has exited with code -1073741819 (0xc0000005) 'Access violation'."
I have a HLS streaming and it occurs every time the stream ends. I thought it might be caused by calling Frame.GoBack() in non GUI thread, but I double checked this, and it is not the reason. Did anyone struggle with this kind of error and know what might be the reason or how to fix this.
I was having the same issue in my application (Universal WP8.1 WinRT).
First, I thought it was because I wasn't using Dispatcher when calling Frame.Navigate (see here).
On searching further, & checking my code, I found that calling Frame.GoBack() from within an event was causing the issue. In my case, it was being called when a user toggles some option in settings page.
But, when I call Frame.GoBack() in the hardware back button press event handler, there is no exception. Everything worked fine.
In your case, you can just stop the streaming on stream end event, & let the user press back button to return to previous page. Or, although I haven't tried this, try using a Dispatcher:
await Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => Frame.GoBack());
Hope this helps.
I was working on a Windows app today, when my errors were no longer being displayed as they usually would. Instead, the debugger just jumps out of the method. The output window makes a note of the exception, but the usual popup trace does not appear.
It works in other projects, and I have put Dim i as Integer = "A" as my first line to try and raise an error, but it just exits the sub on that line.
Any ideas how I get it back?
There is a bug in the interaction between the debugger and the 64-bit version of Windows 7 that strikes in the Load event. An exception is trapped and swallowed by Windows, the debugger never gets a chance to detect that it was unhandled. The only thing you'll see is a "first chance" notification in the Output window. The Load event handler will immediately terminate and your program keeps running as though nothing happened, assuming that it didn't bypass a critical piece of initialization code. This bug has been around for a long time and is well known to Microsoft, apparently it is difficult to fix.
You can work around this bug with Project + Properties, Compile tab, scroll down, Advanced Compile Options button. Change the Target CPU setting to "AnyCPU". Another way to trap it is with Debug + Exceptions, tick the Thrown checkbox on CLR Exceptions. Yet another workaround is to put initialization code in the constructor instead of OnLoad() or the Load event. You only really need Load when you need to know the actual size of the window.
This bug will only strike when you debug. It won't happen on your user's machine.
UPDATE: I expanded a great deal on this mishap in this post.
Under the Debug->Exceptions check that the Common Language Runtime exceptions are checked.
Has your .suo file been deleted by any chance (this is the file that stores your personal state of the solution, your settings, what is expanded / collapsed). You will only really spot this if you suddenly noticed that you had to hit "collapse all" because it had forgotten, it will recreate this when you open the solution, but will do it with default settings.
If so, hit CTRL + ALT + E and re-tick the break on exceptions tick boxes for CLR exceptions.
When an exception is thrown in my app, I expect the debugger to stop running and enter debugging mode, but it does not. Instead, I just get a message in the Immediate Window ('A first chance exception ...'), and the program keeps on running like if nothing happened. However, the sub (in which the exception was thrown) is exited, so statements after the exception are not executed. Since this sub makes the initialization of my program, running becomes very unstable.
How can I tell the debugger to stop execution when an exception is thrown?
(I use VB 2010, and did not change any setting of the debugger.)
UPDATE:
Thanks for the quick answer. Unfortunately, I still can't get it the way I'd like.
On the 'Advenced compile options' page I don't have 'Target CPU'. Maybe it's that I have only VB Express?
If I tick the 'Thrown' checkbox in Debug > Exceptions, execution stops even if I have a catch for that exception, and I don't want that.
Until now I used VB 2008 on 32 bit, and everything worked fine, but since I moved to 2010 64 bit I just can't get it right. Any suggestions?
Debug + Exceptions, tick the Thrown checkbox for "Common Language Runtime Exceptions". The debugger will now stop on the first chance notification.
The usual cause is a catch statement in your code, maybe the VB.NET On Error statement. Or a bug in the 64-bit debugger's interaction with Windows Forms. After it breaks, use Debug + Windows + Call stack and check if the form's Load event handler is on the call stack. The bug causes unhandled exceptions to be swallowed without a diagnostic.
To work around that, use Project + Properties, Compile tab, scroll down, Advanced Compile Options. Change the Target CPU setting to "x86". This is the default setting for VS2010 projects btw. You'll now use the 32-bit debugger, it doesn't have this problem. And you can use Edit + Continue.
I know this is an old thread but I hope it may help others..
I was facing a very similar problem at startup of my forms.
I put my code in "shown event", instead of "load event" and it is SOLVED !
I mean I get exceptions as expected, and my codes do not exit silently.
I know they are different events but for me it didn't make any change.
BTW, my env: VB.net Express 2010 on Win7 64 bit
To get the Target CPU option you must have expert settings selected in VS2010 express. Go to Tool|Options and check expert settings.
I'm buisy on a DirectX10 game engine and i'm having a problem which has nothing to do with DirectX :P The problem is that in the DLL which contains the engine sometimes a DialogBox is called, just like you would do in normal win32. With the only difference that instead of the HINSTANCE i use the HMODULE which i get when loading the DLL.
Everything seems to be working fine, if i step through my code with F10 (Visual C++ 2008) i can even see it going through my DlgMessageProc function and do everything it should do. The only weird thing is that no dialog is shown and that all of a sudden it jumps out of the message loop and just continues with the rest of the code???
Weirly engough I have the same problem when calling MessageBox from inside my DLL, I get no errors, everything seems to be working fine but no window is shown, nor is the code halted (as normal with messageboxes)
The funny thing is that I have some code from a book which uses the same basic architecture as me and if i compile that everything shows just fine??
So my question, is there any hidden option, pragama comment or other thing i should look at if i want to be able to show MessageBoxes and Dialogs from my Dll?
No as i thought, chaning the manifest doesn't help at all. I also created a separate project where i just test the dialog and its proc function and there everything works perfect (links to a .exe instead of dll)
In the visual studio resource editor's property page for the dialog resource there should be an option in which you can specify - "No Fail Create: True".
Usually dialogs fail to create because a common control cannot be created - usually because InitCommonControlsEx has not been called. Setting the No Fail Create flag lets you see dialog and determine which controls are missing.
Other things to check:
Is there a message in the debug window about a first chance exception? Perhaps its 'jumping out' because of an exception that is being caught and silently handled by Win32. Turn on debugging of first chance win32 exceptions in the Dev Studio exceptions dialog to track that down.
Even this wouldn't explain how a MessageBox call would fail to create a message box.
The only times Ive seen MessageBox fail to work were when:
Resource leaks had made the process run out of available user32 handles - have you checked your apps handle counts using task manager?
the system was in the process of being shut down. Have you called PostQuitMessage and then tried to create a dialog/MessageBox?
My application was built with VB.NET. It's an EXE application.
It's already running well on dozens of Windows hosts as an independent app - without a development environment.
Now I try to run it on a Windows 2008 server (as a native app), but the form is not shown - nothing is displayed. When I debug, I see that it's running all "form_load" subroutines until the end, but then nothing is displayed. I find no errors.
What could be the reason? What should I check?
I must say that it works fine on many other Windows machines, but not on Windows 2008 server machines (we tried on another one).
It's not a database application. GUI only.
Thanks in advance!
You say "nothing is displayed." But does the application show up on the Windows Task Bar?
It's possible that the form IS displaying - but that the position is off-screen. For instance, the upper-left-hand corner might be at (1300,1100) or at (-1300,-1100).
Try running it again, but then (when the form OUGHT to be visible) try pressing ALT + SPACE. If your window really does exist, you'll see a system menu (Restore, Move, Size, etc.). In that case, select Size - you ought to be able to use the mouse and/or keyboard arrow keys, to make the window visible.
On the other hand, if the application is supposed to show up in the Windows Task Bar, but it doesn't, then something is happening in (or right after) form_Load that is making the application exit. To double-check if this is happening, try adding this code:
Private Sub Form1_FormClosed(ByVal sender As Object, _
ByVal e As System.Windows.Forms.FormClosedEventArgs) Handles Me.FormClosed
MsgBox("Form is closing")
End Sub
Make sure it is not crashing on launch.
I suppose the appropriate .net Framework is installed on the server?
If nothing is displayed because the application is terminating, it may be due to an unhandled exception. You can tell if the application has terminated by going into Task Manager and seeing if the application is running. If it has terminated, check the Windows Application Event Log. If you're lucky, you'll see an error entry and maybe even a stack trace in that log.