I know that Test Case Management app silently records intellitrace data dump files (http://blogs.msdn.com/jennifer/archive/2008/12/05/visual-studio-team-system-vsts-2010-making-testing-easier.aspx)
I was curious if there is a standalone version that allows to record intellitrace logs (e.g. something that would sit in the tray window).
VSTraceLog.exe under "Microsoft Visual Studio 10.0\Team Tools\TraceDebugger Tools" could be what you are looking for.
VSTraceLog.exe /? to get the different options.
A simple example: VSTracelog.exe launch /cp:CollectionPlan.xml /f:logfilename.tdlog TheExecutableToLog.exe
You'll want to copy the file "Microsoft Visual Studio 10.0\Team Tools\TraceDebugger Tools\en\CollectionPlan.xml" to a known location and modify it. Open the XML file and find "DiagnosticEventInstrumentation" set the enabled attribute to true. Optionally you can enable "TraceInstrumentation" as well. Enabling TraceInstrumentation would be like enabling Tools->Options->IntelliTrace->events and call information.
With Visual Studio 2012 there is a fully supported standalone version available. http://www.microsoft.com/en-us/download/details.aspx?id=29036
You might also be interested in http://naveensrinivasan.com/2010/04/28/useintellitracewithoutvsnet/, which describes how to run IntelliTrace on PCs that don't have Visual Studio installed. In this case it would apply to you if you aren't running VS2010 Ultimate.
Related
Our previous development systems used Windows XP and Windows 7. Debugging C++ DLLs from Visual Studio worked great.
A recent move to Windows 10 has resulted in an annoying problem. We can debug once (using F5), but the 2nd time results in a linker error:
MyProg fatal error LNK1201: error writing to program database 'MyProg.pdb'
Trying to delete the .pdb manually in Explorer while Visual Studio is still open results in the error:
The action can't be completed because the file is open in devenv.exe
It doesn't matter whether you hit a breakpoint or not. Just start debugging once results in the problem. Re-starting Visual Studio resolves the issue (in the sense that you can debug once, but then you get the problem again).
If relevant:
x86 Visual Studio 2003.NET
targeting another x86 application
x64 Windows 10 Pro v1803
After hunting around for several hours some related, but unanswered, questions were found. Following suggestions in this MSDN article, along with some debugging of my own, this solution works:
Download FreePDB, a script written by MSDN user Toni76 (thanks Toni!)
Copy this script to a local folder (say C:\Apps\FreeDPB)
Download the latest version of SysInternals tool Handle (currently v4.21)
Copy handle.exe to C:\Apps\FreeDPB
NB! From the command line, run handle /? once. This is to agree the EULA. The script will not work if you skip this step!
Open Visual Studio, then Project > Properties > Build Events > Pre-Build Event
Set Command Line to C:\Apps\FreeDPB\freepdb $(ProjectName)
Set Description to Delete lock on PDB
...and now you don't need to restart Visual Studio to debug a 2nd time!
From comments, this works with multiple versions of Visual Studio on multiple versions of Windows.
Update
A more radical solution is described here which involves replacing a core Visual Studio DLL (NatDbgDE.dll). This solution only works for Visual Studio 2003 SP1, though.
In my case it was due to "Process Explorer" program, which was open alongside with my Visual Studio(I used it to check some properties of the exe I've created). After closing it problem solved.
I am getting this message in the Diagnostic Tools window in Visual Studio 2015 when debugging a C# MVC web application.
I've checked solutions to a similar problem: Visual Studio 2015 diagnostics tool does not support current debugging configuration but using administrator mode and disabling "Use Managed Compatibility Mode" do not help. I've also tried disabling Options -> Debugging -> Just-In-Time -> Script, which still has no effect. It's the only reference I can find to 'Script' and I don't know how to change my debug engine.
I've also tried this solution from the web about setting the Visual Studio locale to the same as the OS, but they're both using US English. https://blogs.msdn.microsoft.com/devops/2015/05/06/known-issue-for-diagnostics-tool-window-in-visual-studio-2015-rc-the-diagnostic-tools-failed-unexpectedly/
Can anyone tell me what I'm doing wrong?
My error message is
The diagnostic tools failed unexpectedly. The Diagnostic Hub output in the Output window may contain additional information.
Try to modify the Environment Variable TEMP as following rules and reopen Visual Studio. That works for me, maybe it also works for you. My IDE is Visual Studio Enterprise 2015 Update 3.
It must only one path in TEMP. For example,
Fail:%USERPROFILE%\AppData\Local\Temp;C:\OTHER_PATH
Fail: %USERPROFILE%\AppData\Local\Temp\;C:\OTHER_PATH
Pass: %USERPROFILE%\AppData\Local\Temp
If you create a default MVC web app, and then debug your app, could you use the Diagnostics tool in your side? I test it in my side, it works well using the default settings, my OS and VS all are the English version. So you use the same language version, am I right?
If possible, you could check the following steps:
Reset your VS settings:
Open VS, TOOLS->Import and Export Settings Wizard->Reset all settings->select “No, just reset settings, overwriting my current settings”->Choose a Default Collection of settings(I often use the General or C#).
Please use the latest VS2015 with update 3.
Maybe you could download and install the match VS version as your windows directly, debug it again.
First of all, I am not asking the same question here. ( This may be a duplicate post on Stack Overflow.) I have searched other solutions on MSDN, ASP .NET Forum, Stack Overflow, Code Project and everywhere on internet. But none of them solved my problem. These are the links that I found:
http://blogs.msdn.com/b/kirillosenkov/archive/2012/01/11/vs-hangs-for-1-minute-on-start-debugging-check-for-dead-symbol-paths.aspx
http://www.codeproject.com/Questions/272109/Visual-Studio-2010-Hangs-When-Debugging-App
And a lot more...
My CPU is 4th Generation Intel Core i7 and memory capacity is 8 GB. I think it is more than recommended hardware requirements.
Problem:
My visual studio hangs on these situations.
Opening a solution (Hangs for a minute when I open a file from solution explorer)
Running the debugging (Freezes consistently when I click on debug button) and
Stopping the debugging (Freezes immediately after the UI returns to the Developer layout after debugging)
I have tried the following steps:
I ensured that I deleted all the breakpoints in the solution.
I ensured that I am not using any resources from network drive.
I ensured Step over properties is enabled.
I ensured Enable .NET Framework source stepping is NOT enabled.
I start visual studio with SafeMode to suppress extensions
I cleared watch window.
I cleaned and rebuilt the solution.
Before I encounter this problem, I installed "Install Web Components" Visual Studio Add-In a few weeks ago. May be because of extensions and add-ins?
How can I do it to solve my problem?
If you suspect that Visual Studio settings get corrupted after installing "Install Web Component" bundle, why don't you try to reset the settings?
You can perform the steps below to reset Visual Studio settings:
Open Visual Studio Command Prompt (2010) under Start menu > All Programs > Microsoft Visual Studio 2010 > Visual Studio Tools (Run it with Administrator privilege: Right-click the program > Run as administrator)
Run devenv /Resetsettings to restore the IDE's default settings, optionally resets to the specified VSSettings file.
Run devenv /ResetSkipPkgs to clear all SkipLoading tags added to VSPackages.
Run devenv /Safemode to see if you can apply it correctly. This can eliminate the possibility that third party Add-ins or packages are causing problems.
Open your solution in Safemode and see whether it works.
Found this to happen also when the solution is connected to a Team Foundation Server and the service is not available at the moment, so the solution could not connect. In this case do not end the Visual Studio instance and wait until a message box show up giving the option to Go Offline. This is usually associated with the "Visual Studio is waiting for an operation to complete...." notification message.
My solution was simply to reload a saved GOOD (backup) copy of my settings (made a year ago). Worth trying before resetting everything to blank. My VS2010 would take 60 seconds to start debugging and approx. 3 minutes to stop debugging. I saved the corrupted settings and to my surprise they were over 3MB instead of 260Kb. I loaded the good backup copy and everything is great again :-)
If Visual Studio doesn't respond only when attempting to open solutions, then open a raw instance of Visual Studio then Reset Settings
Check How to: Reset Your Settings from the Tools Menu
http://msdn.microsoft.com/en-us/library/ms247075%28v=vs.90%29.aspx
This is Visual Studio 2013 and Windows 8.1
Open developer command prompt.
Start -> All programs -> Visual Studio -> Visual studio tools -> developer command prompt
Make sure that you don't have any pending changes that need to be checked in.
run this command : "tf workspace /delete 'your workspace/ machine name'"
yes for removing the unnecessary pending changes if at all present.
Is there any tool or plugin that can synchronise visual studio so that when I use it at home the same windows are open in the same configuration as when I left work?
Have you tried Pepper?
Will sync (most of) your settings to the/ a cloud somewhere.
Visual Studio Live Share may be able to be used to get this behaviour.
Is it possible to use windbg commands like !locks and .loadby sos mscorwks from the Visual Studio command window (in a debug session)? I've noticed I can use eg k to print a stack trace, so I was wondering if there is some way to get access to the other commands.
Yes you can do this.
Attach Visual studio 2008 to your process for debugging.
Break at some code.
Go to immediate window
type !load sos
Now you are free to use any of the windbg commands like !EEHeap,!DumpHeap
There are some conditions. You need to enable unmanaged code debugging in your project properties. Normally in 64 bit version studio doesn't support this.
Have fun.
Visual Studio 2012 has the "Windows User Mode Debugger" transport in the "Attach to Process" dialog. This allows you to use windbg commands in the immediate window.
Source: Use the WinDbg Engine in Visual Studio User-Mode Debugging
Starting with Windows Driver Development Kit (WDK) 8.0 the Windows debugger is integrated into Visual Studio (see Debugging Environments). Installing the WDK on top of a Visual Studio installation will enable a developer to pick a number of debuggers from the Attach to Process dialog, or set the debugging engine in a project's Debugger settings. This has been verified for Visual Studio 2012 and 2013. The way I read the MSDN link above, this should also work for any other IDE that is supported by the WDK 8.0 and above.
While WinDbg offers a lot of powerful commands, there are some drawbacks as well. This list is not exhaustive, and merely contains those issues I did encounter:
Cannot attach to more than one process at a time. While not generally an issue, this is quite unfortunate, if you do need to debug more than one process at a time. The Visual Studio debugger can attach to any number of processes simultaneously.
WinDbg will not use the symbol settings from your Visual Studio IDE (tested on VS 2012 Update 4). While you can configure the IDE where to look for debugging symbols, WinDbg will not honor those settings. WinDbg will use the _NT_SYMBOL_PATH environment variable, and/or the configuration set through .sympath.
Different syntax for function breakpoints. This is a minor annoyance, since you cannot use Visual Studio's syntax to specify function breakpoints. This also means, that function breakpoints are ignored that have been set using the Visual Studio syntax. What's more annoying, though, you do get a warning dialog for each when launching a debuggee.
No support for Tracepoints. I've been using tracepoints extensively, to unintrusively insert tracing into a debuggee. If you are using tracepoints as well, this may prove to be more than just an annoyance.