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.
Related
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!
I am using Code::Blocks 12.11 on Windows 7.
I am writing small programs for learning and they don't appear to contain any infinite loops but regardless, Build->Abort does not work in those situations in which I find that I have to use it for some reason after Build->Run.
In this most recent case, the following is displayed in the "Build log" tab of the "Logs & others" window at the bottom of the screen.
Checking for existence: C:\CodeBlocks\Test_Cpp11\bin\Debug\Test_Cpp11.exe Executing:
"C:\Program Files (x86)\CodeBlocks/cb_console_runner.exe"
"C:\CodeBlocks\Test_Cpp11\bin\Debug\Test_Cpp11.exe" (in
C:\CodeBlocks\Test_Cpp11.)
I exited Code::Blocks, came back in, reopened the project, and immediately ran the program and it ran fine.
EDIT: I found out the problem. If the "console window" - that came up to display cout statements - is still open, then you will have a greyed out Build->Run and Build->Build items until you close that window. My assumption that I needed to do Build->Abort at that point was incorrect. As pointed out in the answer below, that would not abort a running project process anyway, only a build/compile process that may be running.
THis happens when the previous execution is not terminated properly.
On windows, Open up the task manager and kill the commandline processes which contain the output of the previous run. Doing so will restore the build / run to icons to green and they are rendered available.
To kill the running process while you are debugging, click on the red-color 'X' button on the debug bar. This is the button named "Stop Debugging" in the image shown below.
In Code::Blocks, the Build->Abort menu item will abort building (making or compiling) your project. It has nothing to do with killing a running process. Hope this helps you.
When the application has completed and returned from its main function, it will prompt you to "Press any key to continue".
Once you do so, this will abort the launched process and the build buttons will no longer be greyed out.
I'm trying to use OllyDbg's "Execute Till User Code" feature (which is essential for me) but it never works.
I first tried it on a program which called MessageBoxA. When it called it I paused the program in the debugger and issued OllyDbg to execute till user code, but the program was still paused and completely frozen. I couldn't even click the MessageBox's OK button, or even make it continue from OllyDbg. When I tried too hard to make it continue it just crashed.
So I decided to write an application in NASM (to have complete control) and tried it there. The MessageBoxA popped, I paused, executed till user code, I could press the OK button this time, but OllyDbg didn't pause the program once I did. The program just executed as if nothing happened.
Why doesn't it work and what can I do to solve it?
OllyDbg 1.10 (No Plugins)
Windows 7 Ultimate SP1 64-bit
Update:
I've tried to use OllyDbg 2.0 but the Execute till user code button is completely disabled for some reason.
I ran into the same issue while following Lena's tutorial #4 and I think I've figured it out. When I press Alt+F9 to "Execute Until User Code," I notice that all but one thread in the Threads window (Alt+T) have the suspend flag set. Evidently, Alt+F9 only resumes one thread. Fortunately, OllyDbg has the ability to manually resume the other threads by right clicking on them and selecting "Resume" (or by using the + key). For me, this was sufficient both to unfreeze the dialog and to get OllyDbg to pause immediately after the call to MessageBoxA.
I am trying to launch an application via the ShellExecute() API call. This application contains only a main function which does some processing and exits.
Now I have put DebugBreak() in starting of main. When ShellExecute() is called the application is launched successfully but it does not ask for breaking.
How can I debug my application when launched from other application using ShellExecute()?
I am using VC++ .
If DebugBreak() isn't workign for you, try _CrtDbgBreak(). Note that _CrtDbgBreak only works in a debug build.
_CrtDebugBreak definitely works for me to make a launched process break on startup, although I'm pretty sure DebugBreak does also.
Note that both functions will make it look like the process has crashed, since they raise an exception. That is normal and gives you the opportunity to attach a debugger via the crash dialog. (The crash dialog also lets you terminate the process; don't use that, obviously.)
Also note that if you have a catch-all SEH exception handler around your main then the exception raise by DebugBreak & friends will be swallowed up and the app will simply exit without showing the crash dialog or letting you attach to it.
You can't do this with VC++; with WinDbg this is just .childdbg 1 to debug all child processes. With VC++, you can use Image File Execution Options in a pinch - check out http://codereflect.com/2009/09/20/how-to-debug-child-process-using-windbgvisual-studio/ for more info. Really though, if you've got the time to learn WinDbg, it's much better at this.
you can try this, it's ok in xp system.
app.exe is your application name,
-s1...-s3 is command line arguments.
HINSTANCE hRet = ShellExecute(NULL, L"open", L"vsjitdebugger.exe", L" app.exe -s1 a1 -s2 a2 a3 -s3", szExePath, SW_SHOW);
There is now a Microsoft Child Process Debugging Power Tool.
The method I use for things like this is to embed some interactive code, which you can either delete afterwards, comment out or conditionally enable. In a few cases we have this code enabled by querying an environment variable which is set by the tool that launches the main application. This allows me to click a check box, hit launch and have the breakpoint dialog in seconds.
if (MessageBox(NULL,
_T("Attach the debugger now, then choose Yes to hit a breakpoint"),
_T("Attach Debugger"),
MB_YESNO) == IDYES)
__debugbreak();
This gives you the ability to attach the debugger when the dialog box appears and the option to hit a breakpoint or not. My earlier versions didn't give me the option and after a while I realised some of the time I wanted the breakpoint, and some of the time I didn't.
I guess prety much everyone who does a lot of debugging have a handy macro in Visual Studio (with shortcut to it on a toolbar) which when called automatically attaches to a particular process (identified by name).
it saves a lot of time rather than clicking "Debug" -> "Attach to the process ...", but it only works if one is running a single instance of the process one wants to attach to. If theres is more than one instance of particular process in memory - the first one (with a smaller PID?) is being choose by debugger.
Does anyone have a macro which shows a dialog (if more that 1 process with a specified name running) and lets developer to select to one he/she really wants to attach to.
I guess the selection could be made based on a windwow caption text (which would be suffice in most of cases) and when the particular instance is selected macro passes the PID of the process to the Debugger object?
If someone has that macro or knows how to write it - please share.
Thanks.
You can always attach to all instances...
Here is a macro I used when debugging asp.net applications - these typically have both a UI and a Webservice and I need to attach to both.
Sub AttachToAspNET()
Try
Dim process As EnvDTE.Process
Dim listProcess As New List(Of String)
listProcess.Add("aspnet_wp.exe")
listProcess.Add("w3wp.exe")
listProcess.Add("webdev.webserver.exe")
For Each process In DTE.Debugger.LocalProcesses
For Each procname As String In listProcess
If process.Name.ToLower.IndexOf(procname) <> -1 Then
process.Attach()
End If
Next
Next
ListDebuggedProcesses()
Catch ex As System.Exception
MsgBox(ex.Message)
End Try
End Sub