I have been experiencing some difficulty with visual studio freezing up lately, and I have determined that the problem seems to be sourcevault. I am running vs 2003 on Server 2003.
Often but not always when I shut down VS with an ascx file left open in the editor (in HTML view). I am unable to restart visual studio. VS will just freeze up with the name of the offending file in the title bar. It never times out; just sits there until I kill the process.
When I disable sourcevault integration, I can again open the solution without any problems.
As an alternative to disabling sourcevault integration, I can also delete the .SOU file and open the solution no problem. (the SOU file contains the list of files to be opened on startup.)
VS also freezes randomly while opening a file in html view. (double clicking a file) This is most annoying as I often loose whatever I have been working on.
This may be difficult to diagnose; the problem seems to be random. Sometimes files open correctly, sometimes they hang.
I have already tried reinstalling visual studio. I have also tried opening up ascx files with a different editor. neither seem to help.
Any help would be appreciated,
Jeremy
Client Information
Vault Client Version: 3.0.6.2856
.Net Framework Version: 1.1.4322.2300
Operating System: Microsoft(R) Windows(R) Server 2003, Standard Edition
Service Pack: 1.0
OS Version: 5.2.3790
Total Physical Memory: 2 GB
Time Zone: (GMT-05:00) Eastern Time (US & Canada)
Server Information
Vault Server Version: 3.0.6.2856
.Net Framework Version: 1.1.4322.573
Operating System: Microsoft(R) Windows(R) Server 2003, Standard Edition
Service Pack: 0.0
OS Version: 5.2.3790
Timezone: (GMT-05:00) Eastern Time (US & Canada)
SQL Version: Microsoft SQL Server 2000 - 8.00.818 (Intel X86)
May 31 2003 16:08:15
Copyright (c) 1988-2003 Microsoft Corporation
Developer Edition on Windows NT 5.2 (Build 3790: )
License Information
2 serial number(s):
1 of 2: 5 users, permanent
2 of 2: 25 users, permanent
VS 2003 Freezes up on load
Moderator: SourceGear
The place to start would be with client side logging, so that the next time this happens it will be captured in the log.
See this KB article for details:
http://support.sourcegear.com/viewtopic.php?t=1534
See the section for enabling logging for Visual Studio .NET 2003.
You probably should log all classes. Note that this log can get very large, so turn off logging after you've captured the events you want.
Then email it to Linda at sourcegear.com.
See this KB article for details:
http://support.sourcegear.com/viewtopic.php?t=1534
See the section for enabling logging for Visual Studio .NET 2003.
You probably should log all classes. Note that this log can get very large, so turn off logging after you've captured the events you want.
Then email it to Linda at sourcegear.com.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager
before I enabled logging, I located the vault logs to examine them.
I noticed many instances of the same error.
I enabled logging, fired up visual studio which promptly froze up. The last success message from vault to show up was at 10:19:59
I noticed the last thing in the log was the same error I noticed earlier.
6/22/2005 10:19:59 AM <generic>: [<No Name>:2776] FileSystemWatcher error, probably overflow of its internal buffer: System.IO.ErrorEventArgs Too many changes at once in directory:C:\Work\FHLB\cast.
6/22/2005 10:19:59 AM <generic>: [<No Name>:2776] FileSystemWatcher error, probably overflow of its internal buffer: System.IO.ErrorEventArgs Too many changes at once in directory:C:\Work\FHLB\cast.
6/22/2005 10:20:00 AM <generic>: [Watcher:3608] WatcherThread: beginning full scan
I'll send you the entire log via email.
I noticed many instances of the same error.
I enabled logging, fired up visual studio which promptly froze up. The last success message from vault to show up was at 10:19:59
I noticed the last thing in the log was the same error I noticed earlier.
6/22/2005 10:19:59 AM <generic>: [<No Name>:2776] FileSystemWatcher error, probably overflow of its internal buffer: System.IO.ErrorEventArgs Too many changes at once in directory:C:\Work\FHLB\cast.
6/22/2005 10:19:59 AM <generic>: [<No Name>:2776] FileSystemWatcher error, probably overflow of its internal buffer: System.IO.ErrorEventArgs Too many changes at once in directory:C:\Work\FHLB\cast.
6/22/2005 10:20:00 AM <generic>: [Watcher:3608] WatcherThread: beginning full scan
I'll send you the entire log via email.
VS 2003 hangs opening aspx that inherits from page base
This bug reminds me of a bug that has plagued us for close to two years since Vault 1.2.2 through Vault 3.1 (just tried 3.1 and unfortunately, bug still resurfaced!) Here is a description of the bug that we've had a lot of discussion about privately over email over the past two years! Maybe some ideas will flow now????!?!?!?!
Symptoms:
When opening an .aspx web form in Visual Studio.Net 2003 in HTML or HTML Design view, the IDE hangs, the CPU jumps to 100% forcing you to force quit. The symptom can also occur if a webform happened to be left open in design view the last time you used the IDE and you simply open the solution (the CPU will jump to 100% and the IDE hangs because it is unable to open the aspx file).
Connection between these Symptoms and Vault (i.e., why Vault is to blame):
Unbinding C# solution from Vault Source Control in the IDE makes the symptoms disappear (immediately)!
Rebinding solution in IDE to Vault Source Control makes the symptoms reappear (immediately)!
When switching IDE integration to Visual Source Safe (instead of Vault) the symptoms did not appear! (thus ruling out Visual Studio.Net 2003 source control API being at fault)
if you look at the task manager when the IDE hangs, the application tab shows TWO IDE instances which seems to point to the fact that the IDE is launching another process – we’ve concluded that that process is Vault.
Symptoms appear even when we upgraded to Vault 3.1 (and 2.0.5 and Vault 1.2.2)
Steps to Reproduce:
We work with a C# web application that has aspx pages. The code behind of the .aspx page must inherit from a class that in-turn inherits from System.Web.UI.Page. The specific class in question is a class of ours called PageBase. In Visual Studio.Net 2003, in our C# Web Application that is source controlled by Vault, we open an .aspx page either in design view or HTML view. On one machine, on one day, the symptoms may not appear, but then the next day they will! However, the symptoms ONLY appear on aspx pages that inherit from this particular class. There is nothing in this class that is “non-standard,” or out of the ordinary, and again, I have gone several months, without symptoms, while using this class, unmodified. We have not (not for lack of trying!!!!) been able to determine what exactly in this class is the problem, or what the EXACT sequence of steps to reproduce the problem is to explain why sometimes we experience the bug, and sometimes it mysteriously goes away!!
Workaround:
When the IDE hangs, our best workaround is to force quit VS.net and open the code-behind of any aspx page in the site, and change it to inherit from System.Web.UI.Page. Then, open the aspx page in the VS Designer window. It will open without hanging. Now, change the code-behind class to inherit from our PageBase class. Now reopen the aspx page and it will not hang! This seems to allow the IDE to get passed the compilation phase where it fails. However, while this workaround will last a little while, the symptoms will soon reappear, perhaps when you recompile the solution, or when you open and close the solution again! So the workaround is short-lived.
What is Going On (to the best of our knowledge)
On the surface, you might say that this is a Visual Studio.Net defect that has to do with HTML design view of ASPX pages! However, it is 100% clear that this has to do with source control, now that we’ve tried it with Visual Source Safe without error! When opening an aspx page that inherits from System.Web.UI.Page in Visual Studio, you can tell the IDE is “compiling” the assembly for that project in order to display the page. When the page inherits from PageBase, and the IDE hangs, it hangs at the point that it’s trying to compile the assembly for that web project. After a force quit, if you look at the bin directory of the web project, you will see all the referenced dlls of the project, except the assembly of the project itself! That is because it’s compilation failed, and it has something to do with a call to Vault Source control!!!
Other information
After performing a force quit, when reopening the solution, more often than not we are unable to compile our project because an error unable to copy a particular DataAccess dll because it is in use. The may or may not have to do with this bug, but it is a very common symptom that happens after we force quit after the IDE hangs!
Enabling Logging - Is FileSystemWatcher relevant?
Upon reading this thread, I was thrilled to see that the user got some logging to show that the FileSystemWatcher was having a problem! We have never gotten any logging of the IDE to show anything (I'm assuming that turning on vault client logging is irrelevant to this issue, and instead we've put in the SCCLogFileName registry entry to log the IDE). We still get no log of what is going on at the moment an aspx page is opened and VS hangs.
We personally think this has to do with Vault putting a file system lock on a temporary file that VS creates in the "design" view compilation that takes place when we open an ASPX page whose code behind inherits from a PageBase class that in turn inherits from System.Web.UI.Page!!!
We are still maddened by this bug! Any insight will help!!!
Symptoms:
When opening an .aspx web form in Visual Studio.Net 2003 in HTML or HTML Design view, the IDE hangs, the CPU jumps to 100% forcing you to force quit. The symptom can also occur if a webform happened to be left open in design view the last time you used the IDE and you simply open the solution (the CPU will jump to 100% and the IDE hangs because it is unable to open the aspx file).
Connection between these Symptoms and Vault (i.e., why Vault is to blame):
Unbinding C# solution from Vault Source Control in the IDE makes the symptoms disappear (immediately)!
Rebinding solution in IDE to Vault Source Control makes the symptoms reappear (immediately)!
When switching IDE integration to Visual Source Safe (instead of Vault) the symptoms did not appear! (thus ruling out Visual Studio.Net 2003 source control API being at fault)
if you look at the task manager when the IDE hangs, the application tab shows TWO IDE instances which seems to point to the fact that the IDE is launching another process – we’ve concluded that that process is Vault.
Symptoms appear even when we upgraded to Vault 3.1 (and 2.0.5 and Vault 1.2.2)
Steps to Reproduce:
We work with a C# web application that has aspx pages. The code behind of the .aspx page must inherit from a class that in-turn inherits from System.Web.UI.Page. The specific class in question is a class of ours called PageBase. In Visual Studio.Net 2003, in our C# Web Application that is source controlled by Vault, we open an .aspx page either in design view or HTML view. On one machine, on one day, the symptoms may not appear, but then the next day they will! However, the symptoms ONLY appear on aspx pages that inherit from this particular class. There is nothing in this class that is “non-standard,” or out of the ordinary, and again, I have gone several months, without symptoms, while using this class, unmodified. We have not (not for lack of trying!!!!) been able to determine what exactly in this class is the problem, or what the EXACT sequence of steps to reproduce the problem is to explain why sometimes we experience the bug, and sometimes it mysteriously goes away!!
Workaround:
When the IDE hangs, our best workaround is to force quit VS.net and open the code-behind of any aspx page in the site, and change it to inherit from System.Web.UI.Page. Then, open the aspx page in the VS Designer window. It will open without hanging. Now, change the code-behind class to inherit from our PageBase class. Now reopen the aspx page and it will not hang! This seems to allow the IDE to get passed the compilation phase where it fails. However, while this workaround will last a little while, the symptoms will soon reappear, perhaps when you recompile the solution, or when you open and close the solution again! So the workaround is short-lived.
What is Going On (to the best of our knowledge)
On the surface, you might say that this is a Visual Studio.Net defect that has to do with HTML design view of ASPX pages! However, it is 100% clear that this has to do with source control, now that we’ve tried it with Visual Source Safe without error! When opening an aspx page that inherits from System.Web.UI.Page in Visual Studio, you can tell the IDE is “compiling” the assembly for that project in order to display the page. When the page inherits from PageBase, and the IDE hangs, it hangs at the point that it’s trying to compile the assembly for that web project. After a force quit, if you look at the bin directory of the web project, you will see all the referenced dlls of the project, except the assembly of the project itself! That is because it’s compilation failed, and it has something to do with a call to Vault Source control!!!
Other information
After performing a force quit, when reopening the solution, more often than not we are unable to compile our project because an error unable to copy a particular DataAccess dll because it is in use. The may or may not have to do with this bug, but it is a very common symptom that happens after we force quit after the IDE hangs!
Enabling Logging - Is FileSystemWatcher relevant?
Upon reading this thread, I was thrilled to see that the user got some logging to show that the FileSystemWatcher was having a problem! We have never gotten any logging of the IDE to show anything (I'm assuming that turning on vault client logging is irrelevant to this issue, and instead we've put in the SCCLogFileName registry entry to log the IDE). We still get no log of what is going on at the moment an aspx page is opened and VS hangs.
We personally think this has to do with Vault putting a file system lock on a temporary file that VS creates in the "design" view compilation that takes place when we open an ASPX page whose code behind inherits from a PageBase class that in turn inherits from System.Web.UI.Page!!!
We are still maddened by this bug! Any insight will help!!!
That is exactly what is happening with me.
My C# project contains many User control (ascx) files which inherit from a base class we created which inherits from System.Web.UI.UserControl.
The modified version 3.1 did not correct the problem. I am not convinced the FileSystemWatcher has anything to do with the problem since I have seen this error occur on other workstations which do not seem to experience this problem. I have also had the IDE hang without seeing the buffer overflow error in the log.
Aedell, do you have Sharepoint installed on the machine? That is the only other piece of "Non standard" software I have installed on my machine.
I now work with my solution in a disconnected state. It is a pain, but so is loosing all your unsaved work when the IDE hangs.
My C# project contains many User control (ascx) files which inherit from a base class we created which inherits from System.Web.UI.UserControl.
The modified version 3.1 did not correct the problem. I am not convinced the FileSystemWatcher has anything to do with the problem since I have seen this error occur on other workstations which do not seem to experience this problem. I have also had the IDE hang without seeing the buffer overflow error in the log.
Aedell, do you have Sharepoint installed on the machine? That is the only other piece of "Non standard" software I have installed on my machine.
I now work with my solution in a disconnected state. It is a pain, but so is loosing all your unsaved work when the IDE hangs.
Yes, it looks like the buffer overflow/scanning issue appears to be a false lead.
We'd love to be able to reproduce this here, but we've never been able to.
I would suggest turning on the regular Vault GUI logging (because the IDE component uses the same underlying libraries), and seeing whether the hang happens in a Vault call.
It might have something to do with Vault being a .Net app hosted by Visual Studio, but it is hard to tell.
We'd love to be able to reproduce this here, but we've never been able to.
I would suggest turning on the regular Vault GUI logging (because the IDE component uses the same underlying libraries), and seeing whether the hang happens in a Vault call.
It might have something to do with Vault being a .Net app hosted by Visual Studio, but it is hard to tell.
VS 2003 hangs opening aspx that inherits from page base
Yes! I had a feeling your bug was the same. There is something going on with how VS.Net does some "quasi" compilation when you open an aspx or ascx page. It doesn't do a "regular" compile. I feel it's compiling the base class to some temporary file somewhere (?), and I'd guess that temporary file may have a locking conflict with Vault (?). Does anyone know what VS is doing when you open an aspx page? Remember, if you don't inherit from the base class, and use Page or UserControl as the base class, the bug does not occur! This seems to point to the fact that those built-in .Net assemblies are already compiled in the GAC, while our custom base classes are not!Jeremy wrote:My C# project contains many User control (ascx) files which inherit from a base class we created which inherits from System.Web.UI.UserControl..
No. No sharepoint on any of our Windows XP Pro workstations.Jeremy wrote:Aedell, do you have Sharepoint installed on the machine? That is the only other piece of "Non standard" software I have installed on my machine.
Dan: I've turned on Vault GUI Client logging as well, but as far as I can tell, it doesn't log ANYTHING when using the IDE only... and the bug we are discussion only happens when using the IDE. Can you clarify what you meant by logging the Vault Client?Dan wrote:I would suggest turning on the regular Vault GUI logging (because the IDE component uses the same underlying libraries), and seeing whether the hang happens in a Vault call.
I certainly hope we can get to the bottom of this some day!Dan wrote:We'd love to be able to reproduce this here, but we've never been able to.
I think we're closer than ever now - if we can crack what's going on with base class "design" time compilation... Again, this bug seems to often coincide (but not always) with VS saying that a certain dll is locked and can't be overwritten... I'm still thinking file locking is key here (?)Adam
Take a look at http://support.sourcegear.com/viewtopic.php?t=1534 for info on logging in the underlying Vault classes. Note that you need to have a config file called devenv.exe.config in order to log when invoked from the IDE (see the KB article for details).
Dumb question: Does the VS output window have anything useful in it?
Dumb question: Does the VS output window have anything useful in it?
Thanks Dan. We enabled the devenv.exe.config logging. It certainly does log a lot 
, however, at the critical moment of opening an ASPX page, nothing is logged.
This seems to be a lovely VS "feature" (that other developers may be familiar with) forces the developer to quit VS (which releases the file lock), delete the dll, and reopen the solution. Other dlls that get locked are sometimes in folders called "obj" e.g.,: someproject\obj\some.dll. This is an annoying bug as well, that some have attributed to an intellisense locking large dlls on get latest version, which will reproduce this behavior every time, however we get the dll locking even without getting latest version.
It is anecdotal evidence that the bug we are encountering seems to coincide with days that we experience the dll locking bug. Please see
http://support.microsoft.com/default.as ... -us;887818
, however, at the critical moment of opening an ASPX page, nothing is logged.Not a dumb question. Well, of course, the IDE and therefore the output window is frozen, so it does NOT in fact have any ouptut at all. However, again, very often a dll of ours in another class library project will show up in the output window during the course of working as being locked up. For example, we will compile our web project. The compile will fail. The output window will say compile failed because the data.dll or dataaccess.dll in our inetpub\wwwroot\webproj\bin is locked, and can't be overwritten.Dan wrote:Dumb question: Does the VS output window have anything useful in it?
This seems to be a lovely VS "feature" (that other developers may be familiar with) forces the developer to quit VS (which releases the file lock), delete the dll, and reopen the solution. Other dlls that get locked are sometimes in folders called "obj" e.g.,: someproject\obj\some.dll. This is an annoying bug as well, that some have attributed to an intellisense locking large dlls on get latest version, which will reproduce this behavior every time, however we get the dll locking even without getting latest version.
It is anecdotal evidence that the bug we are encountering seems to coincide with days that we experience the dll locking bug. Please see
http://support.microsoft.com/default.as ... -us;887818
Adam
What's the status on (at least user configurable) removal of the working scans (FileSystemWatcher)? I didn't see the fix--mentioned above--in the 3.1 release notes, nor was there any noticeable change in the SCC configuration (through VS IDE) from version 3.0.x to 3.1.x.dan wrote:We were not able to figure out exactly what was happening here, but we removed the working folder scan on startup when invoked from the IDE, and the problem went away. This will be included in the release version of 3.1
The problem(s), mentioned by aedell and jeremy, still persist in version 3.1, and no logging is gathered for when the IDE freezes, even with all the logging mechanisms (devenx.exe.config, registry key SCCServerPath add, and VaultGUIClient.exe.config) in place.
We still want to use Vault, but the problem is wasting more time, than the benefits of using Vault are providing.
Your timely response is much appreciated.
jwinn,
I'm just posting to let you know that Dan is out of the office today and I think he's the only one here with enough history on this issue to provide clueful comments. He will return on Monday.
In the meantime, I can confirm that in Vault 3.1.0, the IDE client never uses FileSystemWatcher. Since the problem persists for you in 3.1, this does seem to confirm the suspicions earlier in this thread that FileSystemWatcher and working folder scans are unrelated to the problem.
Sorry for all this frustration. As far as I can tell, this problem is still a complete mystery. Dan may know something I don't.
I'm just posting to let you know that Dan is out of the office today and I think he's the only one here with enough history on this issue to provide clueful comments. He will return on Monday.
In the meantime, I can confirm that in Vault 3.1.0, the IDE client never uses FileSystemWatcher. Since the problem persists for you in 3.1, this does seem to confirm the suspicions earlier in this thread that FileSystemWatcher and working folder scans are unrelated to the problem.
Sorry for all this frustration. As far as I can tell, this problem is still a complete mystery. Dan may know something I don't.
Eric Sink
Software Craftsman
SourceGear
Software Craftsman
SourceGear
This is a problem that we've never been able to reproduce in house. If I remember correctly, creating simple solutions that try to reproduce it (that inherit from System.Web.UI.Page) don't necessary show the problem - only a very complex, real-life solution will do so.
jwinn, are you on the same team as aedell, and using the same solution?
I guess the next step would be to send us the entire solution and see if we are able to reproduce it here. It is likely some strange interaction with VS and a .Net application running on top (which Vault is).
I realize that upgrading to VS 2005 is probably not something you would want to do to test it out, but that would be valuable info to know whether it is an issue specific to VS 2003.
jwinn, are you on the same team as aedell, and using the same solution?
I guess the next step would be to send us the entire solution and see if we are able to reproduce it here. It is likely some strange interaction with VS and a .Net application running on top (which Vault is).
I realize that upgrading to VS 2005 is probably not something you would want to do to test it out, but that would be valuable info to know whether it is an issue specific to VS 2003.
I believe I have the same problem with a winforms app.
We started using Vault 3.1.5 a couple weeks ago, and some of thhe developers have begun to encounter a very similar problem with a windows form file. Anyone else out there still having the problem...I would really like to see this problem put to rest.
Jeff
Jeff