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.
Related
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.
I have some code in Form Load event. It is doing fine. But when it reaches to pick data from database, no commands are executing after that. There is no error at all but it just goes silent.
I tested it as follows:
MsgBox("1")
vrStudentName = DsGetPprStatusfromEnrSummary.tblPaperEnrSummary.Rows(0).Item("StudentName")
MsgBox("2")
Please advise.
Thanks
Furqan
Message Box one is showing data but not the message box two. In fact, the second message box statement is not showing any response at all.
This is a nasty problem on 64-bit operating systems. Any exception raised in code that's run from a form's Load event is swallowed without a diagnostic. This is an old problem that is not getting solved because the DevDiv and the Windows groups at Microsoft are pointing fingers at each other. My finger is pointing at the Windows group but that doesn't help either.
Two basic ways to solve this problem:
Project + Properties, Compile tab, scroll down, Advanced Compile Options, change the Target CPU option from x86 to AnyCPU. This disables the Wow64 emulation layer that swallows the exception.
Debug + Exceptions, tick the Thrown box for "Common Language Runtime Exceptions". The debugger stops as soon as the exception is thrown.
Also keep in mind that it is very rarely necessary to use the OnLoad method or Load event. Only code that requires the Size or Location or Handle of the form to be accurate needs it. Anything else belongs in the constructor of the form. That Load is used so often is a VB6 anachronism, carried over in the designer design which made the Load event the default event for a Form. Add a constructor by typing "Sub New".
Well, it seems pretty obvious that the call to DsGetPprStatusfromEnrSummary.tblPaperEnrSummary is never returning; which means the problem is IN THERE somewhere.
So what on eath is it? I'm guessing it's a DataSet, yes?
But you've referenced it staticly, which is YuckyPooPoo(TM) IMHO, because it's a complex artifact, and you've rendered EVERYTHING which references it unisolatable, and therefore fundamentally untestable!
Received answer on Codeproject
In the dialog that comes up, put a tick in every checkbox under both "Thrown" and "Unhandled". Press OK.
Now, when you run your app though the debugger, it will break for any exception, even if you have an active handler. This should help you track down the problem.
Issue RESOLVED
I'm writing a simple Cocoa Application, no core data or multiple document support. Running on a Mac Pro, OS X 10.6.6, Xcode 3.2.3.
I have reduced my application to the following code in my AppDelegate class:
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSOpenPanel *openPanel = [NSOpenPanel openPanel];
[openPanel runModal];
return;
}
From within the debugger, I will run my application. As expected a somewhat not-to-useful OpenPanel will appear. I will click Cancel and it will disappear. All this is as expected. When I click [Command + Q] to Quit the application, the UI will go away but the debugger will indicate that the application is still running (as does the console output).
Based upon all the information I'm reading, I should not have to do anything else in order for this to run right. I've downloaded several examples on the Open Panel's usage but most use the deprecated methods of opening modal giving additional information as parameters. FWIW, I tried those methods and am still seeing the same result.
One last item, when the Open dialog appears, just for an instant I see a message box asking me something to the extent if I want my application to receive incoming connections. The dialog quickly disappears. I don't know if that is part of my problem or not. [Update - this deals with my Firewall being turned on.]
Yes, I'm fairly new at Objective C but not at programming in general. Any words of wisdom is greatly appreciated!
2011.02.07 - Update:
I have walked the debugger line by line without incident. There is no indication of any program failure in the console window.
I say that the debugger is still active after [Command + Q] because the Stop Process toolbar button is still enabled as is the Break button. Further the console indicates that after I tell the application to terminate (either via the menu or key command) that it is still running. The following is the Complete console output from start of run to after I Quit the application.
Program loaded.
run
[Switching to process 62370]
Running...
The Activity Monitor (system tool) will show my application terminating (no longer shows up as a process) but the Debugger will still not transition to "edit" mode - if I tell Xcode to run the debugger again, it will ask me if it's OK to Stop the current debugging session. If I was in Windows I would start looking for background threads keeping the process alive but as far as I know, NSOpenPanel should not be doing something like that.
I have further simplified the program to nothing more than creating a brand new Cocoa application and inserting the code snippet above - no other additions to the template project or updates in any way.
And lastly, when the application is run under the Leaks Performance Tool, everything runs fine when the panel is created but never used. When created and actually used though, at the end of the run I will get the following message in the tool "insufficient task_for_pid privileges (leakagent64)". Googling this hurts. If I read it right, the debugger does not have sufficient permissions to fully kill the target process ??? Now that sounds stupid but ... It does not make sense!
Another update - I just downloaded and ran FunHouse, one of the SDK sample applications that also uses NSOpenPanel. Well don't I feel special. It exhibits the same exact behavior. So from this I conclude either Apple has a bug in their code, my machine is special and messed up, and finally, it is Not my code that is at fault. That being the best part. Tomorrow, I will use a friends Mac and see if the same behavior is exhibited on his box.
This is just too weird.
I rebooted my box, took it to work and found it worked like a charm! I will assume this is fixed and has nothing to do with any other connected devices at home as compared to at work.
If it re-exhibits at home, then it is a network/device issue. Thanks all for your inputs and suggestions! Very much appreciated.
What, specifically, does the debugger say? It's possible that your program crashed, so the debugger is showing you information about the crash.
What if you omit any attempt to run an Open panel?
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?