(Note, this question has been marked answered in Debugging Sharepoint timer jobs but I'm still having trouble)
I'm unable to debug my SharePoint timer job. Usually I can do this by setting one of these:
Debugger.Launch()
Trace.Assert(false)
But a dialog is not shown. I have a log4net OutputDebugStringAppender so that I can use DebugView to monitor output, and I can see that DEBUG ASSERTION FAILED is being written to the debug log. I've tried removing the appender in case it might mess up something, but with no luck.
(Rebuild, restart, IIS reset, Service reset, pdb files in assembly is done)
So why is a dialog not shown? I could really use some help with debugging this timer job and would be very thankful for any ideas.
You are most probably running your app in Debug mode instead of Release mode. In debug mode you already have Debugger attached so it won't launch.
You can find if debugger is attached or not by this:
System.Diagnostics.Debugger.IsAttached
So try like this:
if(!System.Diagnostics.Debugger.IsAttached)
{
System.Diagnostics.Debugger.Launch();
}
Trace.Assert(false)//Trace is not bound to Debug or Release mode so will always run
Related
In all of my searching, I have not come across any trick, plug-in, or setting that would allow me to pre-populate a Watch Window for use during debugging.
The well-known steps to watch a variable in Visual Studio 2017 is to set a breakpoint (perhaps on the first instance of a variable being assigned a value), then, adding the variable to a Watch Window. On subsequent runs, that watched variable should remain in the Watch Window.
Is there a way to accomplish pre-populating the Watch Window before a debugging session? I have code that runs in a timed sequence. Taking the extended time during an execution break to pause and set up a watch causes the program to crash. Such timeout crashes while setting up variable watch objects makes for difficult interaction with the debugger. Pre-populating the watch list would help considerably.
I know that I could use a technique such as using Debug.Print(...) statements, which are printed to the Output Window during code execution. However, this doesn't allow me the control and visual feedback to my debugging efforts that comes from a Watch Window.
Watches can only be evaluated when you are paused in the debugger, say on a breakpoint. They can't be evaluated during normal execution. Your options to get around this limiation are:
Add Debug.Print(...) or something similar to your code that outputs a value.
Similar to #1 add a TracePoint which you'll find in the actions setting of a breakpoints setting (that's the gear icon when you hover over a breakpoint). When the TracePoints are hit they will then evaluate the expression that you specficied in the actions window and log it to the Output window. The advantage of TracePoints over adding your own logging is that you can turn it off and on without building your code. More info at: https://learn.microsoft.com/en-us/visualstudio/debugger/using-breakpoints?view=vs-2019#BKMK_Print_to_the_Output_window_with_tracepoints
Use the VS Enterprise only feature Snapshots which is part of IntelliTrace. Basically set your breakpoints but rather than stopping on them to look at the watch just continue. Each time you stop a snapshot of the process will be taken capturing the state of your application at that time. Then once you're finished use the Diagnostic Tools window to select each of the snasphots and activate them. For each snapshot you can use the debugger just as if you stopped the application. So you can use watches and inspect etc. Of course you can't step as the app has already ran but you can go to the next snapshot etc. More info at: https://learn.microsoft.com/en-us/visualstudio/debugger/view-snapshots-with-intellitrace?view=vs-2019 and https://devblogs.microsoft.com/visualstudio/step-back-while-debugging-with-intellitrace/
How Can Watch Variables be Configured in a Watch Window Before Running
a Debug Session in VS2017?
I'm afraid the answer is negative.For now,the Watch window can only be configured after the debug session start.It's like a runtime window only occurs during debugging.
So we can't pre-populate it before debug session for now. In other words, it's by design.
As alternative ways,you can follow Andy's detailed suggestions above.
And since your needs is meaningful in some specific debugging situation, you can also post your suggestion on development community like a user voice to add a new feature.
i coded a big project that runs when I open it in Debug or Release Mode, but when i open it without Debugging (ctrl + f5) it crashs. I searched a long time to find the heap error, but didnt find anything. The problem is i need the running .exe of the programm, so i wanted to ask if there is a possibility to link the windows debugger to the .exe so it always starts with it.
If it doesn't crash right away, maybe this helps:
You can run the executable.
Open your solution in visual studio. Make sure it's the same build.
Open the DEBUG menu and click attach to process.
A window will open, listing all processes that are running. Select the executable that's crashing
Click the DEBUG menu again and select Exceptions (ctrl-alt-E)
Make sure the checkbox "Thrown" is checked for Common Language Runtime Exceptions
Now crash your application.. It will halt at the line that causes it.
Also look for environment directives. like #IF DEBUG #END IF. or #IF RELEASE That kind of stuff. Tricked me a couple of times too..
Good luck. Hope this helps!
You can do various things. First make sure you have a "big out try block" in main. i.e. put the main logic in a try can catch exceptions and report these clearly. This probably isn't what's happening in your case.
You can attach a debugger - including Visual Studio, to a running process - see the "Attach to process" option under the debug menu. If it's built with debug symbols, which you can do, even for release code this may help. If it's optimised you may find it difficult though.
Finally, you could generate a crash dump and inspect that after it's failed. See docs on MiniDumpWriteDump. There are several examples on its usage. Or you can install an abort handler: See here. This mentions _set_abort_behavior which if invoked with _CALL_REPORTFAULT will generate a crash dump too.
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 a series of Google Unit Tests that are launched via a bat file. Some of these tests are broken and a window appears when they run:
Microsoft Visual C++ Debug Library
Debug Error!
... Info about error
This window waits for a user to press Abort, Retry, Ignore. Of course, this halts my test. Currently, I delete the broken tests before I run the batch. I want a way to force this window to abort or ignore - so I don't need to skip the broken tests.
This problem is similar to; however, I cannot write to reg keys
How do I disable the 'Debug / Close Application' dialog on Windows Vista?
Update: My manager says this window might not appear if this project was in release. Trying to do that now. However, if there is a solution besides changing my project to release, I would appreciate it! :D
That's what you get from a failed assert() in the source code. Useful to debug the test. But actually running unit tests against code that was compiled in the Debug configuration is not useful. Your customer isn't going to run the Debug build either.
Only test the Release build, that disables those assert() calls as well.
I tried the following steps in order to debug a particular custom timer ( installed and activated):
Copied the both .dll and .pdb files in the GAC.
Restarted the timer services.
Attached both w3wp and OWSTimer.exe processes.
But the debugging is still not taking place. The debugger placed is empty circle which displays this message:
The breakpoint will not currently be hit. No symbols have been loaded for this document.
The OWSTimer is shown in a diff username. Does It needs to be run from my account?
Why debugging is not working?
Debugging Timer Jobs can be hard... The steps you took sound about right, but you can also do some more:
Timer Jobs run in OWSTimer.exe - you only need to attach to that one
Restart the timer service. For good measure throw in a restart, deploy, restart, iisreset ;-)
Did you do a DEBUG Build or RELEASE build?
Make sure you actually RUN your timer job (as in trigger it)
If your breakpoints are still not hit, do something ugly: use Debugger.Launch() or Debugger.Break() in your code or an assertion which will always fails: System.Diagnostics.Trace.Assert(false);
And then there is MSDN for the rescue.
Try loading debug symbols manually and see what it says:
To display the Modules window in break mode or in run mod
On the Debug menu, choose Windows, and then click Modules.
By default, the Modules window sorts modules by load order. However,
you can choose to sort by any column.
In the Modules window, you can see which modules have debugging
symbols loaded. This information appears in the Symbol Status column.
If the status says Skipped loading Cannot find or open the PDB file,
or Loading disabled by include/exclude setting, you can direct the
debugger to download symbols from the Microsoft public symbol servers
or to load symbols from a symbol directory on your computer. For more
information, see How to: Use a Symbol Server and How to: Specify
Symbol Locations and Loading Behavior.
To load symbols manually
In the Modules window, right-click a module for which symbols have not
loaded.
Point to Load Symbols From and then click Microsoft Symbol Servers or
Symbol Path.
copied from MSDN
You can also try to delete Visual Studio cache just to be sure (from command prompt):
del /Q %LOCALAPPDATA%\Microsoft\WebsiteCache
del /Q %LOCALAPPDATA%\Temp\VWDWebCache
del /Q %LOCALAPPDATA%\Microsoft\Team Foundation\1.0\Cache
Just adding to moontear's post.
I had the same loading debug symbols issue until I added in this code to the first line of my Execute method.
public override void Execute(Guid contentDbId)
{
// If in debug mode, trigger a false assertion to give time
// to attach the debugger to the OWSTIMER.EXE process.
#if (DEBUG)
System.Diagnostics.Trace.Assert(false);
#endif
...
Check to make sure your regional settings are correct - append /_layouts/15/regionalsetng.aspx to the CA URL. If you have the wrong time zone, your job may be scheduled for a time in the past. This has hung me up more than once. If this is the case, set the correct time zone (using the url above), stop and start the timer service (either services tool or open command line - net stop sptimerv4 then net start sptimerv4). Then attach to OWSTIMER and debug.
On the Start menu, point to Administrative Tools, and then click Services.
In the Services window, make sure the SharePoint 2010 Timer service is started.
Open the Visual Studio 2010 project that contains your timer job.
Set a breakpoint in the Execute method of your job definition class.
On the Debug menu, click Attach to Process.
In the Attach to Process dialog box, c
If the Attach Security Warning dialog box is displayed, click Attach.
In the SharePoint Central Administration Web site, click Monitoring and then click Review job definitions.
Click the name of your job, and then click Run Now on the Edit Timer Job page.
Verify that the Visual Studio 2010 debugger stops execution on your breakpoint.lick OWSTIMER.EXE, and then click Attach.