I'm trying to debug a TFS build workflow. The build controller and build agents are local and the build template is configured to use them.
In order to debug I'm attaching the debugger to TFSBuildServiceHost, and trigger (queue) the build.
When I set a breakpoint on the outermost Sequence element, the debugger breaks as expected. It also breaks when I set a breakpoint on the "Run On Agent" block. But when I set a breakpoint on any activity inside "Run On Agent", it doesn't stop there (even though in the log I see that it runs).
Just to make sure, I added a "WriteBuildMessage" activity at the begininning of the "Run On Agent" block to print Environment.MachineName and I see that it's the local machine (same as the Controller's).
Note that I want to debug the workflow process and not a particular activity.
In addition, when I hit the breakpoint of the outermost sequence (before "Run On Agent") and press F11 (Step Into) it doesn't stop at the next activity either...
Any help is appreciated!
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'm not talking about Disable All Breakpoints or Start without Debugging.
For example, I have my breakpoints set, including some in loops. I get to a point where I just want the code to run through, without having to disable or toggle off each breakpoint. I want the breakpoints to stay enabled for my next run, but I just want the current execution to complete.
If not, definitely nice to have.
You could use Debug -> Detach All which detaches the debugger but leaves the process running.
I'm using VS 2013 and a SP 2013 farm solution which contains a workflow.
I'm desperately trying to debug my workflow to gain some inside information.
This is what I tried so far:
First of all I set a breakpoint on a GetCurrentItemId Activity
Next I hit F5.
The workflow test host console opens up and the web browser showing my sharepoint site
Next I navigate to my list and start the workflow on any (single) item
The workflow test console stays all black - not a single piece of information to find here
The workflow's internal status changes to "Completed".
...obviously my breakpoint has not been hit. WHY? :(
Solved
Reinstalling VS 2013 did in fact help.
From what I can see you have been starting your workflow in debug mode and trying to debug in on a list event.
Instead of doing that try adding your breakpoints (I always add breakpoint in the first scope) and then go to
Debug -> Attach to Process and look for Microsoft.Workflow.ServiceHost.exe and click attach.
Before doing any work with that list items to trigger the workflow verify that your breakpoints are active - if not try retracting your solution and redeploy, then one more time try attaching it to the WF service.
Hope it helps.
When you attach to the process Microsoft.Workflow.ServiceHost.exe you must select the type of code you will attach to. Just select Workflow and you´ll be able to see the workflow context variables.
I have a ASP.NET 4.0 WEB API application running that modifies some database records.
My code iterates through Orders and Updates:
<[PUT]("ProcessOrders")>
Public Sub PutValue()
Dim Orders as List(of OrderInfo) = DAL.GetOrders()
For Each Order As OrderRequest In Orders
Dim Status As OrderProcessingStatus = Order.Process()
If (Status.isSuccessfullyProcessed) Then
DAL.UpdateOrderStatus(Order.OrderNumber, "SUCCESS")
Else
DAL.UpdateOrderStatus(Order.OrderNumber, "FAIL", Status.ErrorMessage)
End If
Next
End Sub
While debugging in VS2010, I have a break point on the first line where I get the orders.
In VS2010, I click on "Stop Debugging" - expecting that my code will immidietly stop and not execute.
To my surprise, even after I clicked Stop Debugging, the code keeps running and updates my database.
Please help.
Note: I start debugging, and then I use Fiddler to call this method
Thanks,
Simcha
Figured it out. Like Adrian McCarthy said:
If the process is started outside the debugger, and then you attach the debugger, the "Stop Debugging" command simply detaches the debugger from the process, and the process continues to run.
In the end, I used the "Terminate All" under the Debug menu. This actually stops all requests/processes.
If the process is started outside the debugger, and then you attach the debugger, the "Stop Debugging" command simply detaches the debugger from the process, and the process continues to run.
If you want to stop the process, then start it from the debugger. If that's inconvenient (e.g., if the process is started by another process on some event), then you'll have to kill the process in Task Manager and then stop the debugger.
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.