When I try to perform most actions in TFS or a project using TFS, such as add a file to the project the main interface freezes.
I have looked at the call stack, and it appears to be in a deadlock while checking to see if a project is active.
I have tried downloading a completely fresh copy of the code, but that did not help.
I am using VS2010 with SP1 installed.
This is the top of the call stack for the Main Thread when frozen after refreshing my Pending Changes
ntdll.dll!_ZwWaitForSingleObject#12() + 0x15 bytes
ntdll.dll!_ZwWaitForSingleObject#12() + 0x15 bytes
Tfsprovider.dll!NVseeFC::CCriticalSection::Lock() + 0x1d bytes
Tfsprovider.dll!CSccManager::fIsSolutionFolderProject() + 0x3b bytes
Tfsprovider.dll!CSccManager::IsActive() + 0x153 bytes
Tfsprovider.dll!CVsSccUI::Exec_icmdSccRefreshStatus() + 0xbd bytes
Tfsprovider.dll!CVsCommandTargetMap<CVsSccUI,IOleCommandTarget>::Exec() + 0x6a bytes
Tfsprovider.dll!CVsCommandTarget<NVseePkgsVssProvider::CGridBarDialog,IxNull>::Exec() + 0x26 bytes
Tfsprovider.dll!CVsSccPackage::Exec() + 0xa9 bytes
Tfsprovider.dll!CVsSccHatHelper::RefreshStatus() + 0x3c bytes
[Managed to Native Transition]
Microsoft.VisualStudio.TeamFoundation.VersionControl.dll!Microsoft.VisualStudio.TeamFoundation.VersionControl.VssProvider.RefreshStatus() + 0x35 bytes
Microsoft.VisualStudio.TeamFoundation.VersionControl.dll!Microsoft.VisualStudio.TeamFoundation.VersionControl.ToolWindowPendingCheckinsForm.Microsoft.TeamFoundation.VersionControl.Controls.IPendingCheckinHost.RefreshPendingCheckins() + 0x69 bytes
Microsoft.TeamFoundation.VersionControl.Controls.dll!Microsoft.TeamFoundation.VersionControl.Controls.PendingCheckinsChannelControl.OnRefreshPendingCheckins() + 0x3d bytes
Microsoft.TeamFoundation.VersionControl.Controls.dll!Microsoft.TeamFoundation.VersionControl.Controls.PendingCheckinsChannelControl.RefreshSelectedChannel() + 0x22 bytes
Microsoft.VisualStudio.TeamFoundation.VersionControl.dll!Microsoft.VisualStudio.TeamFoundation.VersionControl.CommandHandlerPendingCheckins.Refresh_Exec(Microsoft.VisualStudio.TeamFoundation.CommandHandler handler, Microsoft.VisualStudio.TeamFoundation.CommandHandler.Command command, int commandId) + 0x13 bytes
(Other calls removed, they don't look relevant)
Has anyone else had this issue, or know of a fix for it?
UPDATE:
The interface comes back to life after waiting about 8 minutes. During this time the the TFS server sends me about 60,000 packets of data over the network.
UPDATE 2:
I fixed this by manually recreating the SLN file.
This blocking behaviour was unfortunately a 'by design' problem. In Visual Studio 2010, Team Explorer (and a bunch of other VS components) would perform many operations synchronously and block the UI thread in the Visual Studio shell while they were processing, especially on source control operations.
Making source control operations asynchronous was one of the design goals in Visual Studio 2012 - http://blogs.msdn.com/b/bharry/archive/2011/09/01/wrapping-up-tfs-11-version-control-improvements.aspx
Related
Well i'm in the situation where my dll file passes all the tests but somehow on the production server it sometimes does crash at the least expected moments.
There is actually no possibility to run a debugger but there is a generated stacktrace file:
An exception occured at address 0x0045DA51 in module my.dll
Registers:
EAX: 0x61A881BC
//data......
EFLAGS: 0x00010206
Stack:
+0000: 0x0379F5E4 0x00000000 0x01F1B968 0x00000001
+0010: 0x00000007 0x01F1BCA8 0x00454622 0x742F3500
+0020: 0x00000034 0x00000001 0x00000009 0x00000002
+0030: 0x00000000 0x00000240 0x61A881BC 0x000000A4
+0040: 0x00000000 0x60104F70 0x01F1C15C 0x60104F7D
//more data..
Is there any possibility to load this data into visual studio 2013 to perform some offline debugging (not runtime debugging, I don't know how to call it)?
You should see a crashdump somewhere, a .dmp file. You can export that through sysinternals PrcessExplorer, not sureif that's possible with the default task manager, but that's of course before the crash. I unfortunately don't know anymore how to force a process to generate a .dmp file on crash..
But once you have the .dmp file, you can open it in VS (I think since 2010, maybe 2012).
There are two kinds of dumps, a minidump (basically just including the point of the execution at that point) which is usually < 1 MB, and a "full dump", which incorporates the whole working set of the process afair, which can easily be hundreds of megs. The minidump usually is enough to get started.
Sorry for the incomplete answer, but maybe it gets you on the right track (no time to investigate on my own right now).
I have installed visual studio 2013 Ultimate on Windows 8 enterprise edition.
When I start debugging an mvc project (which pretty empty) : it takes 27 seconds to start the debugging. I assume it's because IIS express 8 is loading symbols and hangs somewhere.
I have tried an empty mvc project and it starts in 10 seconds : which is very unacceptable.
I have tried :
- deleting all breakpoints
- enabling just my code
- unchecking symbols downloading from microsoft servers and downloading them on a local folder on the computer
- disabling intellitrace (was already disabled when i went to see)
- disabling just-in-time (was already disabled when i went to see)
- unplugging the ethernet cable (yes, i am pretty desperate)
- no antivirus is turned on
The first request (when i launch debugging) always take 27 seconds according to glimpse. The controller run under 1 second which is "acceptable". All the next requests are fine.
But I can't work with the 27 seconds each time I launch debugging.
Can someone help me ? I do not know what to do next.
My computer is a dual core 3Ghz with 4 Go of Ram and a 7200 rpm hd. I don't think it's hardware related.
Thank you very much.
UPDATE :
As soon as I start to use NLog in the code, it takes 30 sec to launch the debug mode.
If I comment all the place where I log something, It takes 10 sec. Sometimes less.
How much time you guys take to launch the debug mode ?
It's quit possible you are referencing dead or slow symbol path. For example, you're at home but accessing a symbol path on company's server. Check it under Tools -> Options -> Debug -> Symbol. If it's ok, check your system as follows.
Make sure there is no other process that runs out of your hardware resources.
First check if CPU usage is too high after staring debugging. If CPU usage is too high, use Process Explorer to check what activities VS Is performing. If they are in an extension thread, disable that extension. If they are in VS own thread, it's most likely a VS bug you can report to MS.
Check if memory usage is too high. If VS memory usage is too high, given that you just start simple debugging, it's a VS bug.
If both CPU and memory are ok, it's probably related to IO operation. Use Process Monitor to check which files are being accessed, especially files on remote machine.
This is how I troubleshoot the same problem on my machine. Hope it help you.
I am programming and the sql management studio was left open I detected an unusual amount of data transfer by sql management studio (mostly sending out) it was continuously sending with speed of 16 KB/s and receiving with 6 KB/s.
If it was all download I would have thought that is an update but how about sending data when the program is not even being used. the total amount of send were 47 MB when I saw it.
is this indicating a problem? like being hacked? or is it normal? if it is normal what is the reason?
thanks in advance.
Do you have any add-ins installed ? Some add-ins check for new versions.. Try to deactivate them.
I had a few questions regarding memory in Outlook 2010, Windows 7 64 bit. We have a customer machine, who has Outlook running, with a large number of PST files at about 50 G size. We also have an outlook addin that Outlook loads. We find that on occasion that this addin runs out of memory, doesn’t have any memory to continue with its stuff. Also some of the copy and paste operations in Outlook fail. This problem for the addin doesn’t happen on any of the 100’s of other machines we have the addin running.
Also the number of handles used is over 9,000 (even without any addins), and with addins added it reaches about 11k sometimes. Will this be a problem even in High end Windows 7 64 bit machine?
I have few questions:
Have you guys tested with these large PST files and was everything fine for you?
Is there any way to increase the maximum allocated amount available per addin or for all addins? A registry key perhaps?
Outlook seems to start throwing these errors when it reaches about 300 Meg of memory, even though there is plenty of memory still available. Shouldn’t it grow to 1G if it needs to?
I have an old Windows app, compiled in Visual C++ 6.0, that I need to get working on x64 platforms. The app actually seems to be ok since I used a pretty careful data typing but it interacts with an Outlook add-in that I've had to recompile as an x64 dll just to get it to load into Outlook 64-bit edition.
The add-in sends data to the main application using a WM_COPYDATA message, the data sent is a struct as follows:
{
DWORD dwData1;
char pszData2[32];
DWORD dwData3;
}
Things aren't working so I did some debugging, and it turns out that when the 64-bit add-in sends data to the 32-bit program, the DWORDs are coming in as 64 bits (8 bytes) each, throwing the struct off completely since the program expects 32 bit DWORDs (4 bytes). Looking at the data in memory, I can see the extra 4 bytes for each of the DWORDS, before and after the 32-byte string.
Now doing some research here on Stack Overflow and elsewhere. I see that DWORD supposedly has retained 32-bit length even on x64 platforms as a choice by Microsoft. And doing a TRACE(sizeof(DWORD)) in 64-bit land I get 4 bytes as expected.
So what could be causing my 64-bit add-in to send 64 bits with each DWORD?
I worked around this by changing my struct definition to use DWORD32 but I'd like to "get" the fundamental concept in order to know where else this might be affecting my code.
Sounds like the packing changed.
Use #pragma pack around your structure declaration to prevent the compiler from inserting padding.