I know that I can attach a currently executing process during a debug session. However, I have not found yet how to debug a process that is launched from the Startup project. I have this process being launched with a few parameters, and I would like to step in its initialization, and verify that the arguments that are being passed are correct. In other words, I would like to step into the startup process, and then, after the new process is launched make that the debugger stops in its first breakpoint.
Can someone show me how to configure this scenario using Visual Studio 2010?
Thanks!
Your question isn't completely clear...but, one way is to insert;
System.Diagnostics.Debugger.Break();
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
System.Diagnostics.Debugger.Break();
}
}
}
A screen will pop-up and you can attach debugger:
Click Debug
Select instance of VS2010 you'd like to use (for example, use the one that has your solution open).
If this isn't what you're looking for, please provide additional details
Related
I am using a an assertion framework called Shouldly for C#.
The code looks like this:
[Fact]
public void SimpleTest()
{
false.ShouldBe(true);
}
This is the same as:
[Fact]
public void SimpleTest()
{
Assert.True(false);
}
However, when I debug the example that uses Shouldly, this happens:
But I want this to happen:
The issue
When I debug with Shouldly, Visual Studio steps into the source code of the Shouldly package. I don't want to see the internals, I just want to see what line of the test my code broke on. I can use the Stack Trace to find what line my code broke on but this slows down my flow a lot.
I remember when I first started debugging with Shouldly, VS asked me if it should download the source files (.pdb?) of Shouldly to debug with, I think I accidentally told it yes.
If I look at the Modules I have loaded in VS, it shows me this:
It thinks Shouldly is "User Code" which is probably why it debugs into this. How can I disable this?
I have this issue every time I change VS version. I've managed to fix it before but this time I can't figure it out.
You can disable symbol loading for a loaded module by:
opening the Module window
searching for the module you want to change
right clicking on it and disabling Always Load Automatically
I need to debug a process (starting from an external exe) that terminates immediately after start, so I don't have time to attach. How can I debug it?
UPD I don't have source code of that external exe; I can decompile it, but it's impossible to compile it back
You need to launch your process for debug in a suspended state. Visual Studio is capable of that, just invoke the debugger like this:
devenv /debugexe yourprog.exe <arguments>
The process will start suspended so you'll be able to iterate through first instructions before the crash.
See the detailed answer here.
You just need to open Visual Studio, go to File -> Open -> Project / Solution
and select the exe.
Press F5 and you will see the exception in the Output window. If you go to the Debug -> Exceptions window and select everything you will see the first chance exception before it shutdowns the application.
Note that you don't need the source code at all to do this.
Hope it helps.
You need to start it with the debugger. This will start the program with the debugger already attached.
If you cannot do that with Visual Studio, you can use the Windows Debugging Tools, part of the Windows Driver Kit. Note that the linked kit is for Windows 8.1, you may need to find older versions if you're not on Windows 8.
You can enable debug mode runtime by placing some piece of code.
write a method as below:
[Conditional("DEBUG_SERVICE")]
private static void DebugMode()
{
Debugger.Break();
}
and call this method where you want to start debugging, for example in the OnStart event.
you have to build your code with debug mode. dont forget to remove this piece of code after debugging and want to release.
I have declared the PreApplicationStartMethodAttribute on the assembly level like this:
[assembly: PreApplicationStartMethod(typeof(MyApp.Global), "InitializeApplication")]
See this explanation for more details on that.
Here's the declaration of InitializeApplication:
public class Global : HttpApplication
{
public static void InitializeApplication()
{
// Initialization code goes here...
}
}
I am running my application on a local IIS 7.5 instance and I want to debug my InitializeApplication method. I have set a break point on it but it doesn't get hit.
I figure that the code is executed when the Application Pool starts, which to my knowledge is before the point when I hit F5 in Visual Studio.
I have tried to attach the debugger to any IIS related process I could find but to no avail.
I also realize that I can debug using Cassini but I need to fix an IIS related issue here.
So, the question is: how can I debug the PreApplicationStartMethodAttribute designated method?
Try to use IIS Express locally, probably it will be easier to attach debugger to it's process.
You can put a System.Diagnostics.Debugger.Break(); in your initialization code. When the debugger is attached this breakpoint will always hit.
If you want to attach to a process running in IIS, use "Attach to process" (Ctrl + Alt + p), and look for w3wp.exe, you should be able to identify the correct process by the username (apppool user) and type (managed). If the process is not listed, make sure you checked "Show processes from all users". Of course the process needs to be running, so you might need to fire a request first.
A good approach would be to Publish your project to a local folder, which you use as a basepath in IIS, as opposed to pointing IIS directly at your codebase. If you do this, the w3wp process ussualy doesn't need to restart after a republish, so you can easily attach the debugger in subsequent debugging attempts.
We have a solution with multiple projects after running the code from VS the output normally seen from Debug.Writeline statements just cease to appear. I mention the multiple projects because the output from one of the projects continues to appear. However, the other project consistently stops showing the output from the statements.
It's starting to drive me crazy. I should mention this is also occurring for a second developer on the project. Anyone seen this before, or have any ideas?
After being tormented by this for years I finally found the cause and the solution in this Stack Overflow question: vs2010 Debug.WriteLine stops working
It seems that Visual Studio's handinlg of debug.writeline can't handle multiple processeses that each use multiple threads correctly. Eventually the 2 processes will deadlock the portion of visual studio that handles the output, causing it to stop working.
The solution is to wrap your calls to debug.writeline in a class that synchronizes across processes using a named mutex. This prevents multiple processes from writing to debug at the same time, nicely side stepping the whole deadlock problem.
The wrapper:
public class Debug
{
#if DEBUG
private static readonly Mutex DebugMutex =new Mutex(false,#"Global\DebugMutex");
#endif
[Conditional("DEBUG")]
public static void WriteLine(string message)
{
DebugMutex.WaitOne();
System.Diagnostics.Debug.WriteLine(message);
DebugMutex.ReleaseMutex();
}
[Conditional("DEBUG")]
public static void WriteLine(string message, string category)
{
DebugMutex.WaitOne();
System.Diagnostics.Debug.WriteLine(message,category);
DebugMutex.ReleaseMutex();
}
}
Or for those using VB.NET:
Imports System.Threading
Public Class Debug
#If DEBUG Then
Private Shared ReadOnly DebugMutex As New Mutex(False, "Global\DebugMutex")
#End If
<Conditional("DEBUG")> _
Public Shared Sub WriteLine(message As String)
DebugMutex.WaitOne()
System.Diagnostics.Debug.WriteLine(message)
DebugMutex.ReleaseMutex()
End Sub
<Conditional("DEBUG")> _
Public Shared Sub WriteLine(message As String, category As String)
DebugMutex.WaitOne()
System.Diagnostics.Debug.WriteLine(message, category)
DebugMutex.ReleaseMutex()
End Sub
End Class
Follow these steps, it works for me
Right click on your project
Select Properties
Select tab Build
Make sure Define DEBUG constant is checked
Hope that helps
I had the same problem with Visual Studio 2010. None of the above solutions worked in my case, but I solved it like this:
Right-click on your project.
Select Properties.
Click the Compile tab.
Scroll down to "Advanced Compile Options".
Change the value for "Generate debug info" from "pdb-only" to
"Full".
No idea what it's for exactly, but now my Debug.Print statements appear in the Immediate Window again I can finally get back to work.
you should try DebugView from Microsoft SystemInternals.
http://technet.microsoft.com/en-us/sysinternals/bb896647
Regards,
Allen
Try checking if Platform for the solution is set to Any CPU and not x86 (or x64). I used x86 to enable Edit and Continue and then lost Debug output. After going back to AnyCPU the Output is also back.
Got this in VS 2015. All of a sudden all Debug.WriteLine "stops working" (not showing in Output window). After going crazy about this for about an hour I found the problem:
1. Right click In output window (output from Debug)
2. Check that "Program output" is checked
I'm trying to debug some of my unit tests in Visual Studio 2008 and have noticed that breakpoints don't seem to be halting execution.
I kind of assumed that it was as simple as setting a breakpoint and then doing "Test | Debug | Tests in current context" ... but this never actually hits the breakpoints that I've set.
Am I doing something wrong or is this just broken?
Thanks,
Brandon
I had this same problem until I manually attached to the aspnet_wp.exe process first and then clicked on the Debug Tests buttons. Then my breakpoints were finally hit.
In my case System.Diagnostics.Debugger.Break() doesn't stop at testing method.
[TestClass]
public class ContactListTest
{
#region "Constants"
public const string COVERAGE = "CoverageService";
public const string CompanyList = "CompanyList";
public const string ContactList = "ContactList";
#endregion
[TestMethod]
public void GetContactListTest()
{
System.Diagnostics.Debugger.Break();
var ex = new ServiceFilterExpression(COVERAGE);
ex.Expression = new OpBeginsWith("Type", ContactList);
var result = ex.FetchData();
}
}
if you use nUnit you have to do following
start Nunit with the DLL you want to test.
then in Visual Studio go to
Tools -> Attach to Process
choose your nunit process and click "Attach" then it will halt in all your breakpoints
have fun :-)
The official Microsoft workaround/kludge/zomg-I-can't-believe-they-can't-be-arsed-to-provide-this-after-4-years for MSTEST in VS2010, VS2008, and VS2005 is to add System.Diagnostics.Debugger.Break() to the unit test you want to begin debugging from. This works for all projects with debug symbols referenced by the unit test project.
The .NET runtime will prompt you to dump into debug mode (or close the executing unit test program, or ignore the debug line), and (sometimes) allow you to use instance of visual studio that launched the unit test to do so. You can always debug from a new VS instance. Once you hit that System.Diagnostics.Debugger.Break() line, all other breakpoints will be active and hit (assuming they're in the execution stack).
Check the following:
Are the tests marked with [TestClass] and [TestMethod]?
Are you running Debug or Release mode builds? (Doesn't make a huge difference except when it does) Debug is better.
Are you compiling with or without optimizations? Without is better
Try to run All Tests in Solution in check if you hit the breakpoints
and lastly, maybe you have bug and that's why you are not hitting the code?