I have recently started creating some tests in a solution which make use of the Microsoft Fakes framework. All good there, however I've now noticed that when I am debugging my main program (not the tests themselves) and break into the debugger, I have to wait a considerable time.
When I look at Process Explorer I see Fakes.exe running;
"C:\Program Files(x86)\MSBuild\Microsoft\VisualStudio\v12.0\Fakes\fakes.exe" #D:\some\path\My.Tests\obj\Debug\Fakes\fakes.args
Any idea why this is happening when I debug the main program, and how I can prevent it?
Related
I'm trying to debug some web services. I have a number of integration tests setup. I want to attach the debugger to my web process and then execute one of my tests. The problem is Visual Studio doesn't seem to allow me to run a test while I'm already attached to a process. Is there any way around this? The only way I've been able to do it is set a breakpoint in the test prior to calling the webservice, debug the unit test, and then once it hits the breakpoint attach the debugger to my webservice process. That's too many steps.
No I don't believe you could. You can however start up a second instance of visual studio and attach it to your web process with the appropriate breakpoints.
I know this is late but it's still relevant, at least up to VS2019.
What I do to work around this is this:
Attach the debugger to my web service
Detach the debugger
Take note of the 'Reattach to process' shortcut. I think the default is Shift+Alt+P
Run the unit test
Immediately hit the reattach shortcut
Unless your test starts up exceptionally quickly, this method will reattach the debugger before the tests start running.
Allen's answer is better if your machine can handle 2 instances of VS.
With visual studio you can attach to a running process, hit 'pause' (or called break), and even without symbol files or source, you've paused the process and can see a disassembled view.
I would like to achieve this but at the very start of the process. Attaching and pausing as quickly as possible is not the solution I'm looking for :)
For example, if the application was a console based c++ app, gdb can set a break point on main() [or any named function it can find for that matter]. Can something similar be done with visual studio?
But this question is for the more general case - I'd like to be able to start a process and have it pause immediately upon entry (immediately after the kernel launches the process).
http://blogs.msdn.com/b/greggm/archive/2008/09/12/attaching-a-debugger-at-startup.aspx
There are some level of support. But if I were you, I would use WinDbg directly.
I am trying to run a project in Visual Studio 2010, and for some reason it seems like I can't... the command-line window is closed instantly and the debug info is the following:
'exercise01.exe': Loaded 'E:\e\work spaces\C++ projects\exercise01\Debug\exercise01.exe', Symbols loaded.
'exercise01.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open the PDB file
'exercise01.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or open the PDB file
'exercise01.exe': Loaded 'C:\WINDOWS\system32\msvcr100d.dll', Symbols loaded.
The program '[5900] exercise01.exe: Native' has exited with code 0 (0x0).
what might be the cause for these two dll's to not get loaded? and is the fact program exited with code 0 related to my program not running, or is there another problem?
I know others have published such questions before, but unfortunately I couldn't fine any useful info anywhere, so forgive me if I'm re-uploading a question... I'm pretty much a noob when it comes to programming in C, and in Visual Studio in general, so please have patience (:
thank you :)
First thing to check: Are these files actually there. Maybe windows is installed in a different directory and an environment variable is pointing to the wrong place.
If the files are there it is probably an authentication problem. You are running from the command line window. You may be running this in the context of NETWORK SERVICE. Try starting the command window, by right clicking on the menu and selecting "run as administrator".
Basically, your program was started and quickly ran to completion.
When you start debugging a console mode VS project, if your program doesn't stop somewhere or hit a breakpoint, it'll just run the program and when the program exits the window will close.
This is different behavior than if you run the program without the debugger - VS will keep the console window open when the program terminates.
Anyway, you can wither set a breakpoint on main() (or some other convenient location) or instead of simply starting the program with the debugger, you can "single step" into it, which will immediately break into the debugger and stop executuion.
What is the difference between Start Debugging (F5) and Start without Debugging (CTRL-F5) when the code is compiled in Release mode?
I am seeing that CTRL-F5 is 10x faster than F5 for some C++ code. If I am not wrong, the debugger is attached to the executing process for F5 and it is not for CTRL-F5. Since this is Release mode, the compiled code does not have any debugging information. So, if I do not have any breakpoints, the execution times should be the same across the two, isn't it?!
(Assume that the Release and Debug modes are the typical configurations you get when you create a new Visual C++ project.)
The problem is that Windows drops in a special Debug Heap, if it detects that your program is running under a Debugger. This appears to happen at the OS level, and is independent of any Debug/Release mode settings for your compilation.
You can work around this 'feature' by setting an environment variable: _NO_DEBUG_HEAP=1
This same issue has been driving me nuts for a while; today I found the following, from whence this post is derived:
http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx
"Start without debugging" just tells Windows to launch the app as it would normally run.
"Start with debugging" starts the VS debugger and has it run the app within the debugger.
This really doesn't have much to do with the debug/release build settings.
When you build the default 'debug' configuration of your app, you'll have the following main differences to the release build:
The emitted code won't be optimised, so is easier to debug because it more closely matches your source
The compiler & linker will output a .PDB file containing lots of extra information to help a debugger - the presence or absence of this information makes no difference to the performance of the code, just the ease of debugging.
Conditional macros like ASSERT and VERIFY will be no-ops in a release build but active in a debug build.
Each one of these items is independent and optional! You can turn any or all of them on or off and still run the code under the debugger, you just won't find life so easy.
When you run 'with debugging' things perform differently for several reasons:
The VS debugger is very inefficient at starting, partly because everything in VS is slow - on versions prior to VS2010 every pixel of the screen will be repainted about 30 times as the IDE staggers into debug mode with much flashing and flickering.
Depending on how things are configured, the debugger might spend a lot of time at startup trying to load symbols (i.e. PDB files) for lots and lots of OS components which are part of your process - it might try fetching these files over the web, which can take an age in some circumstances.
A number of activities your application normally does (loading DLLs, starting threads, handling exceptions) all cause the debugger to be alerted. This has the effect both of slowing them down and of making them tend to run sequentially.
IsDebuggerPresent() and OutputDebugString() behave differently depending on whether a debugger is attached.
IsDebuggerPresent() simply returns another value, so your program can react to this value and behave differently on purpose. OutputDebugString() returns much faster when there's no debugger attached, so if it's called lots of times you'll see that the program runs much faster without the debugger.
When running 'with debugging' the debug heap is used, even for release mode. This causes severe slowdowns in code using a lot of malloc/free or new/delete, which can happen in C++ code without you noticing it because libraries/classes tend to hide this memory management stuff from you.
I am new to programming.
I know only Start debug before. Maybe start debug suit for some small application develop better.
I found Visual studio IDE provide another method of attach to process for using.
When & Why must I use the attach debugging?
Such as multi-threading application debugging. Client/Service application debugging. etc. Thank you.
Sometimes you need to debug a process started by another program.
For example you need a reliable solution and in order to protect against access violations, memory leaks and other barely recoverable stuff, you have a master program and several worker programs. The master program starts the worker program and passes parameters to it. How do you debug a worker program which is not intended to be started by anything except the master program?
You use "attach to process for that".
Typically you do it this way: insert a statement that blocks the worker program for some time - for example, call Sleep() for 15 seconds. Then you kindly ask the master program to start the worker program. When the worker program is started it blocks and you now have 15 seconds to attach to it.
This way you can debug almost any issues - problems at early startup stages, wrong parameters, etc, which you wouldn't reliably reproduce with "run with debugging".
Attaching to a process is useful if you don't want to debug right from starting the process. For example, debugging usually slows down execution, so it can be quicker to start the app, get it to a state where a bug appears, and then attach a debugger.
It's also useful if you already have an external means of launching the process that you don't want or can't to import into the IDE.
Start debugging from VS launches an instance of the VS webserver and attaches the debugger to it.
Attach to process allows you to attach to any process and debug it, usually you'd do this to your instance of w3wp.exe running your code in IIS
Attach to process is mostly used when you can't run the application from Visual Studio.
For example, if it's a service or if it is a process that has run for a long time and now you want to start debugging it.
Sometimes you also want to debug a remote process, not on your machine - and you can do that using attach to process.