My computer is on Windows 10 build 16299, which is the minimum required version for the UWP restart functionality in CoreApplication.RequestRestartAsync(...). However, after I make the call to restart, with arguments of string.Empty, the App does close and a few seconds later an Exception is thrown from System.Private.CoreLib.dll:
Exception occurred: System.Exception: Exception from HRESULT: 0x80040900
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
I am able to get this information from a Try/Catch block and am running the app from Visual Studio 2017 in debug mode. Before I attempted to catch it, a dialog would appear indicating to debug in another instance of Visual Studio. When the other instance loaded, this was not allowed because it said a debugger was already attached.
Additionally, I tried to catch it by enabling "Common Language Runtime Exceptions", but it did not catch this Exception.
Why is this happening? When I use run this on another Windows 10 machine, the restart works fine. Can I debug or get more information about the Exception in System.Private.CoreLib?
This error will not happen to affect your app's real experience when you install your app and run it without connecting the Visual studio to debug. Visual Studio prevents Windows from suspending an app that is attached to the debugger. This is to allow the user to view the Visual Studio debug UI while the app is running. When you debug this code with Visual Studio, you can see the App status is still Running in your device Task Manager => Details tab after you called this method, so the app can not restart, since prior to Windows 10, version 1803, only one instance of a UWP app could be running at a time. More details about multi-instance UWP, please see Create a multi-instance Universal Windows App.
But in my test on the device OS version 1803 OS build 17134 and Visual studio version 15.7, it will disconnect the Visual Studio debugger automatically after you call CoreApplication.RequestRestartAsync(string.Empty) code.
Related
I've got WinForms application that I'm constantly developing on Windows 10 machine. This application is deployed then to windows 2003 server where some before release tests are performed. The problem with null reference exception occurs when application is closing. What are typical approaches in such situation to check what's the problem is. This issue occurs only on these machine, I can't install visual studio here. What should I try to use to discover such issue?
If you deploy the PDB symbol files to the test environment you should get line numbers in your exception stack traces.
Beyond that you might be able to install the remote debugging tools and connect to the failing instances from your development IDE.
You could also log messages to a file to help you narrow down the issue.
I get an AccessViolationException while debugging an application, but don't get this exception while running this application as release without attached debugger. The application is a very thread-intensive (up to 10000+) network-server (tcp/socket).
The application has run the whole last night compiled as release, without attached debugger and under heavy load. In fact the application didn't ever crash without attached debugger.
When I run the application compiled as Release with attached debugger I get an AccessViolationException-Exception (sometimes). This exception just gets thrown without any hint where this exception occurs. When I press Ok in the appearing exception-box in Visual Studio and then navigate to the thread where the exception occurred. I can't see any code or stacktrace there:
(Thread #186840 has no memory-location.)
This is my (reduced) test-program: example-code. (You should have enough ram and cpu and you should compile it as release. First start the server-application, then generate load with the client-application.)
Now my question(s): How can I debug such errors? Does anyone know about a bug in .NET while debugging such thread-intensive programs?
I'm using Visual Studio 2013 Update 4. The project is a Any Cpu; .NET 4.0 C# project. I have installed all windows update patches and was running this on Windows 8.1. The JIT compiler compiled the code to x64.
I have a WPF application I have created on a Windows 8.1 machine targeting .NET runtime 4.5.1. It runs fine on the development machine.
I am trying to install it on a Windows 7 machine. It has .Net 4.5.1 installed. When I try to run it on the Windows 7 Machine the login window comes up. When I enter the password, the application verifies the password then it crashes. I have verified that it is connecting to the server to verify the password...so it's not a SQL Connection error.
So it appears that it happens when the main application windows is trying to display. Here is the info that gets recorded in the Application log. Notice the framework version. The app is targeting 4.5.1. So I don't understand why it is showing 4.0.30319.
Application: HardwarResources.WPF.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Data.Core.EntityCommandExecutionException
Stack:
at System.Windows.Window.ShowDialog()
at HardwareResources.WPF.MainEntry.Main(System.String[])
The only other pertinent information is Event ID: 1026.
HELP!
I had the same problem when I copied the .exe file (Debug or Release) to another machine and it would simply not work! Showed up in task manager for a few seconds and would disappear leaving only an ArgumentOutOfRangeException and a Kernelbase.dll error in the application event logs. So I decided to install Visual Studio on the machine where the file would not launch. After copying the project folder to a different file structure than on the original machine and hitting compiling it, I found out that I was trying to cut a string (file path) shorter than it was (due to different file structure). So the problem was in the code itself and NOT in any .dlls or .NET versions.
Hope I have helped!
Try adding an event handler to AppDomain.CurrentDomain.UnhandledException to trace more detail about the error. See here for reference on catching unhandled exceptions.
I'm thinking it's something to do with cross-threading, thread synchronization context (requiring invoke) or perhaps missing [STAThread] attribute on Main.
If you're trying to feed data to a dialog, you have to go about it in a thread-safe manner.
When I debug and step any windows phone app on my virtual machine I get the "No Source Available", "The current thread is not currently running code or the call stack could not be obtained".
This is regardless if I debug on the device or the emulator.
It seems like it breaks on the correct breakpoints thou, and continuing works fine.
Stepping through server code works fine.
The virtual machine is just set up for this and only contains Windows 8 (updated), Visual Studio 2012 Pro (complete, updated), Google Chrome, Start8 and Windows Phone SDK 8.0.
Repairing the Visual Studio installation solved the problem.
I have built a WIX project which installs and starts services. For the release version it all seems to work fine but for the debug version I get "insufficient privileges to start service". Any clues why this is happening?
Using .net/Visual studio.
JD.
In my experience this error message is always misleading. Typically it's actually a fault of the service exe. With the messagebox displayed, go to a dos prompt and run the EXE. You'll most likely see a stack trace get displayed. If you see a File Not Found Exception then you are probably missing a dependency. Any other error and it's likely to just be a problem with the code.
Typically when integrating a new service into my installs I will set it to start automatically but not author any specific start events. This lets me work the kinks out with the developers before wiring it up fully into the installer.
Most probable cause: It works on computers that have (or have had) Visual Studio installed, because it means they have debug version of run-time libraries installed as well. It does not work on computers without Visual Studio.