I am trying to remotely debug a project with ASP.NET Core 2.1 that uses IIS as a server using the remote debugger tool, since I was able to establish the connection to the remote server and debug some things using breakpoints, the problem that is currently happening to me is that I can debug the file code as controllers,services, but I cannot debug the Program.cs file code using breakpoints.
Any ideas?
you could check the below things if you are not getting any error but breakpoint didn’t hit:
1)if you are running your code on more than one machine so the first check you are debugging the correct place code.
2)make sure your codding is running and you set the System.Diagnostics.Debugger.Break or __debugbreak( for c++) in your code where you want to set the breakpoint. (do not forget to build your project after adding this code)
3)If you are debugging optimized code, make sure the function where your breakpoint is set isn’t being inlined into another function. The Debugger.Break test described in the previous check can work to test this issue as well.
Add a call to Launch at the beginning of the OnStart()method.
protected override void OnStart(string[] args)
{
System.Diagnostics.Debugger.Launch();
}
How to: Debug the OnStart Method
I'm running an WPF application on a different computer than I am developing it on. Currently I am only using the files from Debug instead of Release. I notice that when I run an application made in Windows Forms, a JIT debugging window shows up when an unhandled exception occurs. This is not the case for my WPF application though. I've check my visual studio settings and I have JIT enabled. Installing visual studio on the computer where the application needs to run is not really possible. Is there a way I can get the JIT debugging window to show up? I am having a real pain in trying to figure out what is going on when the application crashes and doesn't give me any information about it.
So I've not been able to replicate the windows form unhandled exception window but I've got the next best thing using this article:
https://www.wpf-tutorial.com/wpf-application/handling-exceptions/
Adding the following code into app.xaml
DispatcherUnhandledException="Application_DispatcherUnhandledException"
And the following code into app.xaml.cs
public partial class App : Application
{
private void Application_DispatcherUnhandledException(object sender, System.Windows.Threading.DispatcherUnhandledExceptionEventArgs e)
{
MessageBox.Show("An unhandled exception just occurred: " + e.Exception.Message, "Exception Sample", MessageBoxButton.OK, MessageBoxImage.Warning);
e.Handled = true;
}
}
I get a MessageBox telling me what the error is. It also handles the exception and allows the application to continue running.
I'm a super-beginner coder and trying to follow a training video on C# in Visual Studio 2015. The tutorial has me do a new Visual C# project as a Console Application. When I run my code using Ctrl+F5, it launches my code in the console as expected, but the Output --> Show output from build window is completely empty.
I've scoured this site and others for a solution. These are my current VS2015 settings, I've tried changing these with no success:
Show Output window when build starts is CHECKED
Redirect all Output Window text to the Immediate Window is UNchecked.
This is the code, verbatim what is shown in the tutorial:
using System;
namespace Hello
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hello, World");
}
}
}
When the same code is run in the tutorial, the resulting output appears immediately in the Output window:
1>------ Build started: Project: Hello, Configuration: Debug Any CPU ------
1> Hello -> c:\users\[name]\documents\visual studio 2015\Projects\Hello\Hello\bin\Debug\Hello.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
I can see my Output window and I expect to receive this, but I get nothing. First time using Visual Studio, what am I missing?
Prior to adding Console.Read(); at the end of my code, running the code would launch the console with the following output:
Hello, World
Press any key to continue...
But, the build output window in VS remained blank as originally described.
After adding Console.Read();, the output in console no longer contained
Press any key to continue...
However, the build output in VS now displays what is expected as described in Original Post.
If I then remove Console.Read();, reverting back to my original code, the console output is back to original, and the VS build output window still gives expected output...
I suspect that, using Visual Studio for the first time, it had never been directed to write to the Output window, which was accomplished here with Console.Read(); and should do this going forward...
Link to solution I used:
https://stackoverflow.com/a/5301276/11953574
I try to deploy a Click Once Installer but run into a very strange issue:
The installer runs fine but as soon as the application is supposed to start it crashes with the following message
[MyApp] has encountered a problem and needs to close. We are sorry for
the inconvenience.
and no useful information about the cause. As soon as I install Visual Studio Professional 2012 on the same machine, the application starts fine but sometimes behaves very strange (e.g. I have to click to red close button twice to close the application). Funny enough, the problem not always appears, I suspect it has something to do with the order in which I install the .Net Framework/Visual Studio/the Click Once installer.
I am pretty much lost here .....
Btw: The framework targetVersion and supportedRuntime of the Click-Once installer are 4.0 and 4.0.30319 respectively.
Add an UnhandledException handler to your app. This will allow you to see the exception that is causing the crash.
AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);
static void MyHandler(object sender, UnhandledExceptionEventArgs e)
{
Exception ex = (Exception)e.ExceptionObject;
MessageBox.Show("Unhandled domain exception:\n\n" + ex.Message);
}
Note that the use of MessageBox is only for debugging. A logging system should be used for your release version.
I have code written in .NET that only fails when installed as a Windows service. The failure doesn't allow the service to even start. I can't figure out how I can step into the OnStart method.
How to: Debug Windows Service Applications gives a tantalizing clue:
Attaching to the service's process allows you to debug most but not all of the service's code; for example, because the service has already been started, you cannot debug the code in the service's OnStart method this way, or the code in the Main method that is used to load the service. One way to work around this is to create a temporary second service in your service application that exists only to aid in debugging. You can install both services, and then start this "dummy" service to load the service process. Once the temporary service has started the process, you can then use the Debug menu in Visual Studio to attach to the service process.
However, I'm not clear how it is exactly that you are supposed to create the dummy service to load the service process.
One thing you could do as a temporary workaround is to launch the debugger as the first line of code in the OnStart
System.Diagnostics.Debugger.Launch()
This will prompt you for the debugger you'd like to use. Simply have the solution already open in Visual Studio and choose that instance from the list.
I tend to add a method like this:
[Conditional("DEBUG")]
private void AttachDebugger()
{
Debugger.Break();
}
it will only get called on Debug builds of you project and it will pause execution and allow you to attach the debugger.
Once you have a service that is installed using installutil.exe, you can alter the Start Parameters to jump into the debugger if the service is started:
When you manually start the service with the parameter -debugWithVisualStudio (or simply -d), it will automatically detect the correct project, and fire up the interactive debugger in Visual Studio:
To support this functionality, change the service's OnStart() function:
/// <summary>
/// Executed when the service is started.
/// </summary>
/// <param name="args">Command line arguments.</param>
protected override void OnStart(string[] args)
{
try
{
//How to debug when running a Windows Service:
// 1. Right click on the service name in Windows Service Manager.
// 2. Select "Properties".
// 3. In "Start Parameters", enter "-d" (or "-debugWithVisualStudio").
// 4. Now, when you start the service, it will fire up Visual Studio 2012 and break on the line below.
// 5. Make sure you have UAC (User Access Control) turned off, and have Administrator privileges.
#if DEBUG
if (((ICollection<string>)args).Contains("-d")
|| ((ICollection<string>)args).Contains("-debugWithVisualStudio"))
{
Debugger.Launch(); // Launches VS2012 debugger.
}
#endif
ShellStart(args);
base.OnStart(args);
}
catch (Exception ex)
{
// Log exception here.
}
}
(optional) If you want to narrow down to the exact line of code where the service is throwing an error, switch on exceptions from the Visual Studio menu DEBUG .. Exceptions. When you continue debugging, it will break on the exact line that is throwing the exception.
It works just fine!
protected override void OnStart(string[] args)
{
System.Diagnostics.Debugger.Launch();
}
The options above did not appear to work on Windows 8.
I have added Thread.Sleep(15000); into my OnStart() method and set a breakpoint on the next line of the code. This give me 15 seconds to attach VS debugger to my process after starting the service and allowed me to debug the OnStart() method nicely.
You can add a line of code like this:
System.Diagnostics.Debugger.Break()
which will bring up a window prompting you to choose which debugger to use to debug, e.g. allowing you to attach with Visual Studio and step into the code.
see:
http://msdn.microsoft.com/en-us/library/system.diagnostics.debugger.break.aspx
It's possible to set up a companion project to the Windows Service that runs as a console app, but accesses the service methods using Reflection. See here for details and an example: http://ryan.kohn.ca/articles/how-to-debug-a-windows-service-in-csharp-using-reflection/.
Use following Code in Service OnStart Method:
System.Diagnostics.Debugger.Launch();
Choose Visual Studio option from Pop Up message. Remember to run Visual Studio as Administrator.
Note: To use it in only Debug mode, #if DEBUG compiler directive can be used, as follows. This will prevent accidental or Debugging in Release mode on Production server.
#if DEBUG
System.Diagnostics.Debugger.Launch();
#endif
As others have pointed out, you have to add a debugger break to the OnStart-Method:
#if DEBUG
System.Diagnostics.Debugger.Break()
#endif
Also start VisualStudio as Administrator and allow, that a process can automatically be debugged by a different user (as explained here):
reg add "HKCR\AppID\{E62A7A31-6025-408E-87F6-81AEB0DC9347}" /v AppIDFlags /t REG_DWORD /d 8 /f
(I also explained this here: https://stackoverflow.com/a/35715389/5132456 )
I know this is late but this is how we handle debuging Windows services
First create a class which will act as the service.
Add the appropriate methods for starting, stopping, pausing, etc...
Add a windows form to the service project.
In the service code create the service class created above and make the calls needed to start and stop the service in the ServiceBase class
Open the Program.cs and add the following
#if DEBUG
[STAThread]
#endif
static void Main()
{
try
{
#if DEBUG
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);
Application.Run(new DebugForm());
#else
ServiceBase[] ServicesToRun;
ServicesToRun = new ServiceBase[]
{
new YourWindowsService()
};
ServiceBase.Run(ServicesToRun);
#endif
}
catch (Exception e)
{
logger.Error(DateTime.Now.ToString() + " - " + e.Source + " - " + e.ToString() + "\r\n------------------------------------\r\n");
}
}
When you run in DEBUG mode the windows form will launch. Just remember to build in Release mode when finished. Of course the conditional compile variable can be anything you like. You could even create seperate projects so the debug form is its own project.
Hope this helps
You can also try System.Diagnostics.Debugger.Launch() method. It helps in taking the debugger pointer to the specified location and you can then debug you code.
Before this step please install your service.exe using the command line of Visual Studio command prompt - installutil projectservice.exe
Then start your service from the Control Panel -> Administrative Tools -> Computer Management ->Service and Application -> Services -> Your Service Name
If you add Debugger.Launch() in your OnStart method and it doesn't work, you could have the same issue I had, namely, the exception was occurring in the constructor so the OnStart was never called. (head slap)
(sorry if this should have been a comment on someone else' answer, but i don't have enough cred to make comments)
Try adding Debugger.Break inside the problematic method. When the service will start an exception will be thrown and widows should offer to debug it using visual studio.
I usually have a console app that pretends to be the SCM e.g. calls Start, Stop which I can then just F5 into for my main coding/debugging purposes, and use the Debugger.Break for debugging when the service has been installed and started via the SCM.
It means a bit more work to start with, I have a class lib that contains all the service code, with a class that exposes Start and Stop that the Windows Service class and the console app can both call.
Matt
Before I go in the topic one advise. Always use log specially if you are server side developer. Because there are some certain condition which you might not be able to produce while debugging the code in visual studio.
Coming back to topic, I use Envoirnment.UserInteractive flag this is really handy see my code below
public static void Main(string[] args)
{
if (System.Environment.UserInteractive)
{
string parameter = string.Concat(args);
switch (parameter)
{
case "--install":
ManagedInstallerClass.InstallHelper(new string[] { Assembly.GetExecutingAssembly().Location });
break;
case "--uninstall":
ManagedInstallerClass.InstallHelper(new string[] { "/u", Assembly.GetExecutingAssembly().Location });
break;
default:
WindowsService service = new WindowsService();
service.OnStart(args);
Console.ReadKey();
service.OnStop();
break;
}
}
else
{
ServiceBase.Run(new WindowsService());
}
}
From visual studio you will get UserInteractive flag set so i would run it as console application, In addition to that even you can run product build by double clicking it and attaching debugger with it if you like to test it.
I have an interesting way of doing this I add another Configuration called DebugNoService
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'DebugNoService|AnyCPU' ">
<OutputPath>.\</OutputPath>
<AllowUnsafeBlocks>false</AllowUnsafeBlocks>
<BaseAddress>285212672</BaseAddress>
<CheckForOverflowUnderflow>false</CheckForOverflowUnderflow>
<ConfigurationOverrideFile>
</ConfigurationOverrideFile>
<DefineConstants>DEBUG;TRACE;DEBUGNOSERVICE</DefineConstants>
<DocumentationFile>
</DocumentationFile>
<DebugSymbols>true</DebugSymbols>
<FileAlignment>4096</FileAlignment>
<NoStdLib>false</NoStdLib>
<NoWarn>
</NoWarn>
<Optimize>false</Optimize>
<RegisterForComInterop>false</RegisterForComInterop>
<RemoveIntegerChecks>false</RemoveIntegerChecks>
<TreatWarningsAsErrors>false</TreatWarningsAsErrors>
<WarningLevel>4</WarningLevel>
<DebugType>full</DebugType>
<ErrorReport>prompt</ErrorReport>
<UseVSHostingProcess>false</UseVSHostingProcess>
</PropertyGroup>
I use the #if directive.
ProjectInstaller.cs
#if !DEBUGNOSERVICE
static void Main()
{
System.ServiceProcess.ServiceBase[] ServicesToRun;
.....
}
#endif
I add a windows form and I also wrap the windows form in
#if DEBUGNOSERVICE
...
static void Main()
{
Form form;
Application.EnableVisualStyles();
Application.DoEvents();
form = new <the name of the form>();
Application.Run(form);
}
...
#endif
depending on the configuration selected the code either runs as a windows form application that can be easily debugged or as a service.
If seems like a lot of work but it has always worked and makes debugging the code very very easy. You can have all sorts of output added to the form so you can watch it run.