I am trying to enable JIT debugging for my winform application, I want to use Dr Watson to dump the stack trace, but when the exception is happening on my App I get a .NET dialog box (Continue or Quit), the details in this box say that I have to change some values in the machine.config or in the app.config of this application
will i tried to add this:
<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>
to my App.config
But the same box is still shown every time an exception happen, I tried with debug and release versions (and with debug version with pdb file)
How I can get rid of this dialog and enable JIT? I think when I do that I will be able to use Dr Watson (by the way I already ran Drwtsn32.exe -i, and there is no VS installed on that machine)
Add this line to your Main() method, before the Application.Run() call:
Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException);
This disables the ThreadExceptionDialog and trips the AppDomain.UnhandledException event. I doubt you'll get a stack trace out of Watson. You'd better create your own by writing a handler for AppDomain.UnhandledException.
Related
I have a WPF application. To give it an identity to consume UWP APIs, I've added sparse package support. This installs / uninstalls / updates (we're not using MSIX) with my WPF application fine, and my app is running with an identity. It shows in task manager with a Package Name listed on my process.
Now I'm attempting to add context menu support following Microsoft's docs.
I've created a shell extension which will show when opening the context menu for any file and folder, which is pretty much a copy of their sample with different GetIcon(), GetTitle() and Invoke() implementations for IExplorerCommand.
I'm specifying this in the AppxManifest.xml (values anonymised):
<desktop4:Extension Category="windows.fileExplorerContextMenus">
<desktop4:FileExplorerContextMenus>
<desktop5:ItemType Type="*">
<desktop5:Verb Id="MyFileCommand" Clsid="file-guid"/>
</desktop5:ItemType>
<desktop5:ItemType Type="Directory">
<desktop5:Verb Id="MyFolderCommand" Clsid="folder-guid"/>
</desktop5:ItemType>
</desktop4:FileExplorerContextMenus>
</desktop4:Extension>
<com:Extension Category="windows.comServer">
<com:ComServer>
<com:SurrogateServer DisplayName="SSVerbHandler">
<com:Class Id="file-guid" Path="my-shell-extension.dll" ThreadingModel="STA"/>
</com:SurrogateServer>
<com:SurrogateServer DisplayName="SSVerbHandler">
<com:Class Id="folder-guid" Path="my-shell-extension.dll" ThreadingModel="STA"/>
</com:SurrogateServer>
</com:ComServer>
</com:Extension>
This works, my context menu entry is listed and performs the action as expected. But here's the issue: each time the context menu is opened for the first time, it kills the already running instance of my WPF application. By first time, I mean restarting explorer.exe and right clicking on a file or folder.
My gut feeling is this is related to UWP side of things. This is because originally it would always kill my application when right clicking to open a context menu. But with a little trial and error I solved this by configuring multi-instance support in my AppxManifest.xml:
<Package
...
xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
xmlns:iot2="http://schemas.microsoft.com/appx/manifest/iot/windows10/2"
IgnorableNamespaces="uap mp desktop4 iot2">
...
<Applications>
<Application Id="App"
...
desktop4:SupportsMultipleInstances="true"
iot2:SupportsMultipleInstances="true">
...
</Application>
</Applications>
...
</Package>
I'm hoping someone can suggest any troubleshooting ideas as I'm now struggling.
I've sprinkled some ol' trusty MessageBox functions within the shell extension in DllMain, DllCanUnloadNow and DllGetClassObject. But for that first load attempt, no message boxes are shown, no context menu item listed and my application is still killed.
I've poked around in the event viewer hoping to see any errors or warnings listed recently, plus in Applications and Service Logs\Microsoft\Windows\Appx* and Applications and Service Logs\Microsoft\Windows\AppModel-Runtime. Nothing has jumped out at me.
According to this SO anwser, if there's an error with the shell extension itself, it may not show. That does fit, but I'm sceptical as it always works on subsequent attempts, and the previously solved UWP killing issue.
In the scenario where my application stops, using these powershell commands I get:
$process = Start-Process .\MyApp.exe -PassThru -Wait
$process.ExitCode
1
I do have crash logging in my app, but nothing gets logged. This is the only place Environment.Exit(1) is called within the WPF application.
I did try the silent monitoring detection in GFlags on the WPF application, but couldn't seem to trigger it. Only when I manually closed the application. (Ignore Self Exits unchecked for testing). I'm not sure if that's because the exit code is 1.
When the error occurs with process monitor running, I can see lots of ThreadExit before a final ProcessExit with the exit code 1. That would imply it's exiting cleanly with my application itself returning 1?
It's also worth mentioning I've lived in managed / .NET land for the last decade or so, I don't have much experience with C++ (or unmanaged languages in general) or UWP, and the first time I've attempted to write a shell extension.
I am using a variation of Jeff Atwood’s Unhandled Exception handler it steps in when there is an Unhandled Exception in the application. It then logs the error, generates a screen shot and notifies the user.
When compiled in a solution the project generates an EXE that is called when needed. In updating the program I am using Visual Studio 13 to edit the existing settings items in the project properties. In the code I use commands such as this from ConfigurationManager.
string appProduct = unhandledExceptions.Properties.Settings.Default.AppProduct;
I was happy to see that it worked and reflected the changes I made in the IDE. However I couldn’t find the settings in the solutions generated confg file (MyApplication.exe.config). I assumed it was reaching back to the other project folder for the UnhandledExceptions.exe.config.
I created an installer and installed it to a virtual machine. My settings carried over, but again I could not see a config file.
It turns out the values are embedded in the executable UnhandledException.exe.
The project does not have any resources listed. Searching the web and StackOverflow looking a questions that want to do this, and there are a lot of them, it seems this was generally considered not possible and not desirable. Questions usually end in “You don’t want to do that, it’s called config for a reason”.
I may want to turn this off, so it is editable externally. The properties of app.config in both projects are identical.
What setting is making this possible after all? Is it a new capability with Visual Studio 2013?
There is no Visual Studio setting required. If you don’t want the user to have access to the configuration file, don’t include it in the distribution. One can always be added if the settings names are known.
In the description below application generically represents the name of the application being used.
I’ve found through observation some interesting things about the way ConfigurationManager works.
For User settings it will look in the following places in order of priority:
user.config for the application in the user’s AppData area
application.exe.config in the program folder
application.exe itself
Each setting is searched for individually. If your application requests a setting that is not found in either user.config or the application.exe.config it will get it from the executable.
For Application settings it looks in the following places in order of priority:
application.exe.config in the program folder
application.exe itself.
There is no equivalent to user.config for application settings.
Opening the application.exe in the Visual Studio IDE does not reveal a resource for the configuration information.
application.exe.config is handy because it can be modified externally and used as a default value for new installations. Once a setting is overridden in the user.config the value in application.exe.config is ignored.
The same is not true for the AppSettings section, the older configuration method from .Net 1.0. If I delete the configuration file it does not have them in the executable.
These observations were made with Visual Studio 2013 Update 4 and tested in Windows 7 Professional 64-bit. I suspect they are true in all versions.
(see update below)
While running within the VisualStudio 2010 environment, I can easily tell if my Winform application causes an exception. I just have to go to Debug | Exceptions and make sure that both columns of checkboxes are checked. I then run the application and if any exceptions then I get dropped straight into the offending piece of code.
How do I determine exceptions during testing, when I give test build to a tester. I do not want the tester to run within Visual Studio, just as a regular user. I still want to know if there are exceptions and the pertinent details.
Obviosualy, I should be able to control the process, so that when the code gets released normal execution happens.
Yes, I know about and use try/catch blocks, but I am talking about a method similar to Visual Studio exception catcher and reporter, just possibly compiled into the product and used for deployment to beta testers.
Maybe Visual Studio has such a feature, in which case where and how to set up, or possibly a third party component.
[Update:
I added two sub-questions, which you can find at Unhandled Exception next line or exit.
The solution mentioned below sounds great and with a tweak probably works, just not at the moment.
Inside the Visual Studio both 2010 and now 2012 works great. The exception handler gets called, okay after VS breaks at the line and I say to continue. I decided to test outside the VS2012 IDE, good thing for that. The OS traps the bug, shows the standard an "An Unhandled Exception Occurred" dialog giving the details along with a continue and quit buttons. Selecting continue, just continues the application with no trapping into my uber exception handler. Selecting quite, whites-out the application and displays the standard close window dialog. The quit button also does not call my uber handler.
The purpose is so that my exception handler gets called. I do not need an uber exception handler if I am working inside the VS2012 IDE. The purpose of the handler is for end users and beta testers, namely anyone other than myself and who will not have my development station.
So unless I am missing something, the question is still open.
There are code samples in the other question, enough to copy and paste and create a test application in a couple minutes time.
]
Thanks in advance,
Sarah
I don't know of any automagical ways to reports error in Visual Studio but here is what I do.
Hook into the UnhandledException event for the application.
Use a logging framework like nLog or Log4Net to log the exception and other data you get from that event. Or just write to a text file.
Upload that data either from within your application or have the beta-tester send it to you.
Okay, the Google Uberlord took pitty upon me and I found this wonderful article solving the problem. Praise to the almighty Google.
Here is the link:
http://www.switchonthecode.com/tutorials/csharp-tutorial-dealing-with-unhandled-exceptions
Basically, JRadness had the right idea, just slightly in error. He should have used
Application.ThreadException +=
new System.Threading.ThreadExceptionEventHandler(Application_ThreadException);
rather than
AppDomain.CurrentDomain.UnhandledException +=
new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);
The author on Switch on the Code talked of three methods, the first of which is what JRadness proposed and does not work for Windows forms.
The autor even solved my other question of Continue and Abort. The OS got bypassed.
Yeah!!
After too many hours of research I have come up with nothing to solve this problem.
I am running a WPF program in an .xbap page file being hosted on internet explorer. Running the project in Visual Studio 2010 works just fine and generates no errors.
I want to be able to host the webpage on IIS 7.0 and to browse to it with a windows forms application. To test this I created a new website on port 80 in IIS manager. I then published the project to the local website folder and added the autogenerated project certificate file (projectName_TemporaryKey.pfx) to my Trusted Publishers and Trusted Root Certification Authorities.
My problem is this: whenever I try to browse to the file with internet explorer or with my windows forms program, the wpf program stops working. When pulling up the just-in-time debugger, I am informed that there is a System.ExecutionEngineException but am given no source code, no stack trace, and no data outside of an empty Dictionary enumerable. My guess is that this might have something to do with the database call made in the program to another machine, but I can't prove that.
I've tried several things to solve this including repairing my .NET 4.0 framework and altering permissions but nothing seems to be affect the error.
Does anyone know of a way to get more information on this error, or perhaps a step I may have missed when publishing this project?
Thanks very much.
Some things to check:
Windows event log often includes additional exception information (although usually in an awful format)
Output some trace information from your application so you can follow what's happening
Try attaching a debugger to the WPFHost and then stepping through the code
I just discovered this problem today, and I had no idea what caused this problem. My project had been developed for few months.
I have a project(solution), with several projects in there, it works well if I write and debug, by pressing F5.
The problem occur is when I press Ctrl+F5 (to skip debug mode), or run directly from double click the exe, it crashed. The errors dialogs that pop up every times are different, but OutOfMemoryException is the most frequent one.
I had checked to make sure all my projects are .Net 3.5
I put a MessageBox.Show("something") at the beginning of my main project constructor, but it never reach.
I use some registry cleaner to clean/fix my registry, scan for viruses.
I had try to read the meaning of each error and exception, but still no clue why it happen.
These are a series of screenshots if I press Ctrl + F5. (FutureGenerator is some random name I gave to my project.)
Series of screenshot if I run the app from my debug folder, FutureGenerator.exe
I suspect this is caused by framework crashed during Windows Update, but I removed those update that I performed recently, still same. The exe file works on other non development PC, but I don't want to reformat my PC or reinstall my VS, yet, because it's a painful process.
Any idea, anyone?? Million thanks.
You mention v3.5 but the very first screenshot is about v4.
Try repairing your Framework 4 and/or VS2010
I found the problem. It's actually because I added FutureGenerator.exe into Application Verifier by Microsoft. The verifier only support debugging testing.
After I removed FutureGenerator.exe from the Application Verifier, everything's ok.