[Build 919] Massive Problems with VS 2008 Team Edition
Hi,
i have massive problems with R# 4.0 and VS 2008 team edition. I'm working on a client/server project with windows forms. The
solution is not so complex. Just 16 projects with around 20.000 lines of code. But the solution is part of a bigger application and
references lots of assemblies. Nearly each time i load the solution into VS i will receive the error "Try to write protected
memory.". Mostly short after the error occurs VS crashes. The rare times i can work with the solution i notice a horrible bad
performance. For popup menus in the editor i have to wait several seconds. Sometimes the whole IDE freezes for several minutes.
After working a while the compiler hangs infiiiinitely. If i look at the process explorer at this time VS didn't consume any cpu
time. The memory footprint is around 750 MB to 1 GB. As i have 3 GB on the machine this should be no problem. The only thing i could
do was too deinstall R# (and this was very hard for me, because i love your tool). Loading the same solution into VS 2008
Professional i can work without any problems.
For me it seems that the Team Explorer and R# didn't like another. Another reason may be that we use the Infragistics Net Advantage
2007.3 suite because i don't have this installed on my machine with VS 2008 Professional.
Regards
Klaus
Please sign in to leave a comment.
I use ReSharper 4.0 with Visual Studio Team Suite with no such problems at
all.
--
John
"Luedi" <klaus.luedenscheidt@gmx.de> wrote in message
news:g7hnn9$bqb$1@is.intellij.net...
>
>
>
John Saunders wrote:
if you don't have any problem mines may be caused either by the solution structure or the Visual Studio versions. Which version of
the team foundation server do you use? Do you use the Infragistic NetAdvantage control suite?
I had the same problems with the pre-4.0 EAP-Builds they where not so annoying as in the official release build.
Regards
Klaus
Same for me - I use VS Team Edition for Software Testers against TFS 2005. No problems so far!
I use VS2008 (SP1 Beta1) Team Suite (the whole thing) against a TFS 2008
server. No problems with either version 3.x or 4.
--
John
"Luedi" <klaus.luedenscheidt@gmx.de> wrote in message
news:489D18C4.1000200@gmx.de...
>> I use ReSharper 4.0 with Visual Studio Team Suite with no such problems
>> at all.
>>
>
>
>
Hi,
I have had identical problems with R# 3 on VS 2005 Team Edition (at a previous customer's site). VS crashed several times (> 10) a day starting from the day we migrated from SourceSafe to TFS. We never managed to find the reason for this.
Some of the developers gave up on R# - the rest of us just learned to press Ctrl-Shift-S really often :)
/Jesper
Guys,
This is my vs configuration and it runs without a hitch w/ large projects ~ 250k LOC , except for the missing functionality on vista (Header Text Region)
Microsoft Visual Studio 2008
Version 9.0.21022.8 RTM
Microsoft .NET Framework
Version 3.5
Installed Edition: Enterprise
Microsoft Visual Basic 2008
Microsoft Visual C# 2008
Microsoft Visual C++ 2008
Microsoft Visual Studio 2008 Tools for Office
Microsoft Visual Studio Team System 2008 Architecture Edition
Microsoft Visual Studio Team System 2008 Development Edition
Crystal Reports Basic for Visual Studio 2008
Microsoft Visual Web Developer 2008
Gallio integration for Visual Studio Team System
ReSharper 4 Full Edition build 4.0.819.19 on 2008-06-09T22:00:24
Sparx Systems UML Integration Version 3.5.2
Application Styling Configuration Dialog
RemObjects Everwood for .NET 2.0.1.101
as you can see infragistics have no impact on resharper
HTH
BTW 3GB Memory processor 6320 i know , i know kinda slow
but it works
as most of you don't have any trouble with VS 2008 Team edition, maybe my solution structure is the problem. I'm working for a customer who develops a quite big standard application for health care. In the beginning of this year they had trouble with the solution file because they can't compile anymore in areasonable time. So they had split the old solution into several smaller ones. Each solution references all necessary assemblies. The complete application is build via the build server of VSTS. Each solution consists of around 10 to 20 projects and there are around 25 solutions. On average each project in a solution references around 25 assemblies. So the whole structure is quite complex.
What about Antivirus software? Did anyone have trouble because of his virus scanner?. On my company laptop i have installed McAffee and i notice a significant slowdown if the on access scan enginge works on many files (e.g. while copying). The customer i work for at the moment uses the Trend Micro suite.
Regards
Klaus
@Jetbrains: I'm willing to aid the developers to examine the problem. Following errors occurs:
Each time i load the solution the error message "Try to read or write protected memory. The reason for this may be corrupted memory". Nearly each time when i want to open the Team-Explorer Tab VS crashes. The IDE is very slow and sometimes freezes infinetly (one time i go to lunch for an hour or so and the IDE was still frozen). In this case i notice a permanent CPU-time of around 2% to 4% by VS in the process explorer (also the Garbage collector is running sometimes).
I'm working on a HP Laptop (9150 Worksation) with 3 GB Ram on Windows XP SP2. Visual Studio is the original version without any patches and service pack. No other Addins are installed beneath R#.
Klaus, the solution I work with the most in VSTS is about 40 projects,
including over 700 unit tests. The worst that happens is that VS grows to
about 800MB virtual. It takes a while to exit VS sometimes, and if I've had
it open for a day or more, it sometimes crashes before it finishes exiting.
I do suspect ReSharper to be involved, but this is so much better than in
the past!
--
John
"Klaus Luedenscheidt" <no_reply@jetbrains.com> wrote in message
news:29958284.23791218605313184.JavaMail.jive@app4.labs.intellij.net...
>
>
>
>
>
In my personal experience, poorly-configured virus scanners on development workstations are an absolute productivity killer. There is so much disk access during the development process, with tonnes of little reads and writes to discs, even more when tools like R# are in use, when frequently building to run tests, etc. McAfee is particularly problematic in this area, but by far not the worst. If at all possible, get IT to exclude some development-related file extensions from the on-demand scanning configuration. If they can't or won't do that, try to get IT to provide a separate development workstation that has basically nothing other than dev tools and access to source control and issue tracking (and no virus scanner.) If they can't or won't do that, you'll probably have to do what I do: use Process Explorer (or tool of choice) to forcefully terminate all virus scanner processes while doing heavy development work, refrain from using email or all but the safest web sites, etc. while working, and then re-enable the scanner afterward. Doing development work as a regular user (instead of an admin), using FF instead of IE, etc. helps reduce the risk during that time as well.
800MB is not that bad. Over the years at various companies I have worked daily with devenv regularly getting up to as much as 1.5GB with R# 3.x. That said, have you tried using the (memory allocation strategy) wrappers that have been linked to on this forum a few times? They can help keep things running more smoothly as memory creeps up. Additionally, it is worth noting that the managed code running in devenv.exe can't go past 800MB unless you run on 64bit or reconfigure your devenv.exe to be LARGEADDRESSAWARE and then flip the /3GB switch on a machine with at least 3GB of memory. userva tuning might be in order as well if you run into any problems with /3GB but usually it isn't a problem.
(And, as an aside to the usual flurry of people who will sweep in and make all sorts of generalized freak-out statements about LARGEADDRESSAWARE, /3GB, and /userva: Making these configuration changes has literally saved my bacon when working on various projects over the years, and have worked great on a variety of systems. There are times when you can't go 64bit. There are times when you can't break up a huge solution. Go suck rocks.)
As Visual Studio SP1 was released yesterday and R# 4.0.1 RC1 today i installed both to see if my problems may be solved. For the first try i got the same problems as before with the difference that the "read or write protected memory" error is now reported by R#. But after playing a little bit around i found a workaround for my problem:
- Start VS with empty environment
- disable R# in the Addins-Mene
- go to the Team Explorer Tab and let hi connect to the server
- load the solution
- enable R# again
and R# rocks :))
Regards
Klaus
Hello,
As far as I know,
— LARGEADDRESSAWARE is required on 64bit too, otherwise the process still
won't get any mem above 2GB (large-address-unaware processes would store
ownership info in the higher bit of the pointer, so they couldn't be allowed
above 2GB on any platform).
— devenv.exe already has the LARGEADDRESSAWARE flag (as it appeared on my
installation for VS 9.0).
— another choice is running 32-bit Vista, as it's doing some better job of
memory allocation, just like the wrappers mentioned above.
Pity devenv+R# pushes the memory limit that much. We've already started fighting
the mem usage down for 4.5 :)
—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”
Hello,
These are http://www.jetbrains.net/jira/browse/RSRP-77509 and http://www.jetbrains.net/jira/browse/RSRP-77507,
right?
I've reviewed the stack traces of similar exceptions in our tracker. I'm
afraid there isn't any useful info to help us fix the issue.
Probalby the unmanaged (or, rather, mixed-mode) stack traces of the failure
could have more data in them. They could be captured by debugging the Visual
Studio instance that is about to crash with a mixed-mode debugger from another
Visual Studio instance, with "break on exceptions" on for unmanaged exceptions.
DLL symbols should be present for native DLLs, otherwise the stack trace
will be not so informative at all.
—
Serge Baltic
JetBrains, Inc — http://www.jetbrains.com
“Develop with pleasure!”
All true. I have to admit that I didn't realize that VS 2008 came with it flagged out of the box.
Hi Serge,
in my company we are having very similar issues. And we're pretty certain that the cause is Team Explorer with R# not liking each other (you don't get the crashes when you don't use any of the two).
I can somehow (and only sometimes) make the VS crash and with debugger attached I get (among others) this exception:
Unhandled exception at 0x77572dd8 (ole32.dll) in devenv.exe: 0xC0000005: Access violation reading location 0x0000000f.
With following stack trace:
ole32.dll!CoWaitForMultipleHandles() + 0x1bc97 bytes
ole32.dll!CoWaitForMultipleHandles() + 0x1e0d bytes
ole32.dll!ProgIDFromCLSID() + 0x39c bytes
ole32.dll!DcomChannelSetHResult() + 0x590 bytes
ole32.dll!77600e3b()
ole32.dll!DcomChannelSetHResult() + 0x5f4 bytes
ole32.dll!DcomChannelSetHResult() + 0x42a bytes
user32.dll!GetDC() + 0x6d bytes
user32.dll!GetDC() + 0x14f bytes
user32.dll!GetWindowLongW() + 0x127 bytes
user32.dll!DispatchMessageW() + 0xf bytes
msenv.dll!DllMain() + 0x4ce74 bytes
msenv.dll!VStudioMain() + 0x44d9 bytes
msenv.dll!VStudioMain() + 0x4469 bytes
msenv.dll!VStudioMain() + 0x4405 bytes
msenv.dll!VStudioMain() + 0x43d4 bytes
msenv.dll!VStudioMain() + 0x496a bytes
msenv.dll!VStudioMain() + 0x7d bytes
devenv.exe!3000aabc()
devenv.exe!300078f2()
msvcr90.dll!_msize(void * pblock=0x00000002) Line 88 + 0xe bytes C
msvcr90.dll!_onexit_nolock(int (void)* func=0x0072006f) Line 157 + 0x6 bytes C
This will keep on throwing exceptions until process runs out of stack...
If you could provide me with help where / how to get additional debug symbols I can try reproducing the error and get more info out of that.
Thank you for any help.
Jarda
Hello Jaroslav,
Thanks for the stack! However, it looks like memory and/or system tables
are already corrupt, which is most likely the result of previous not-so-fatal
failure.
Also, could you please check that you don't have AppInit_DLLs registry key?
See http://blogs.msdn.com/oldnewthing/archive/2007/12/13/6648400.aspx for
details.
Sincerely,
Ilya Ryzhenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
JM> Hi Serge,
JM> in my company we are having very similar issues. And we're pretty
JM> certain that the cause is Team Explorer with R# not liking each
JM> other (you don't get the crashes when you don't use any of the two).
JM> I can somehow (and only sometimes) make the VS crash and with
JM> debugger attached I get (among others) this exception:
JM>
JM> Unhandled exception at 0x77572dd8 (ole32.dll) in devenv.exe:
JM> 0xC0000005: Access violation reading location 0x0000000f.
JM>
JM> With following stack trace:
JM> ole32.dll!CoWaitForMultipleHandles() + 0x1bc97 bytes
JM> [Frames below may be incorrect and/or missing, no symbols loaded
JM> for ole32.dll]
JM> ole32.dll!CoWaitForMultipleHandles() + 0x1e0d bytes
JM> ole32.dll!ProgIDFromCLSID() + 0x39c bytes
JM> ole32.dll!DcomChannelSetHResult() + 0x590 bytes
JM> ole32.dll!77600e3b()
JM> ole32.dll!DcomChannelSetHResult() + 0x5f4 bytes
JM> ole32.dll!DcomChannelSetHResult() + 0x42a bytes
JM> user32.dll!GetDC() + 0x6d bytes
JM> user32.dll!GetDC() + 0x14f bytes
JM> user32.dll!GetWindowLongW() + 0x127 bytes
JM> user32.dll!DispatchMessageW() + 0xf bytes
JM> msenv.dll!DllMain() + 0x4ce74 bytes
JM> msenv.dll!VStudioMain() + 0x44d9 bytes
JM> msenv.dll!VStudioMain() + 0x4469 bytes
JM> msenv.dll!VStudioMain() + 0x4405 bytes
JM> msenv.dll!VStudioMain() + 0x43d4 bytes
JM> msenv.dll!VStudioMain() + 0x496a bytes
JM> msenv.dll!VStudioMain() + 0x7d bytes
JM> devenv.exe!3000aabc()
JM> devenv.exe!300078f2()
JM> msvcr90.dll!_msize(void * pblock=0x00000002) Line 88 + 0xe bytes C
JM> msvcr90.dll!_onexit_nolock(int (void)* func=0x0072006f) Line 157
JM> + 0x6 bytes C
JM> This will keep on throwing exceptions until process runs out of
JM> stack...
JM>
JM> If you could provide me with help where / how to get additional
JM> debug symbols I can try reproducing the error and get more info out
JM> of that.
JM>
JM> Thank you for any help.
JM> Jarda
Hello Jaroslav,
It'll be very useful if you try to attach WinDBG tool to VS before the crash, reproduce the crash and take
a dump file and send it to us for investigationt.
Thank you.
--
Kirill Falk
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
We are expecting the same problem with the same environment (VS2008+ReSharper 4.0 + Windows XP or Win 2003 server).
I've worked with Microsoft on that problem and reply is:
We had an incident#SRX080723600071 with the same description and results of our investigation:
It looks like there are components running in a different appdomain (possibly a webservice call). We see where JScript
is calling into some object which eventually calls into
JetBrains.UI.Interop.WindowsHook.CoreHookProc. It appears that JetBrains have set a
hook on some thread to watch messages being dispatched to it. We can't tell what
thread from this output, but I suspect it would be the main UI thread since this is
in the JetBrains.UI namespace. We see where that calls
JetBrains.UI.Interop.Win32Declarations.CallNextHookEx, which is likely calling into
User32!CallNextHookEx. In any case, this appears to end up resulting in a
System.SecurityException. It's unclear whether this is handled or not. Please check
with JetBrains whether they expect to see these types of exceptions.
The JetBrains code is involved with the managed exceptions. We know that Visual
Studio is crashing because our ole32!CCliModalLoop instance appears to be released.
We don't have any direct evidence from the dump that Jetbrains caused that, but we
do know that removing JetBrains from the IDE allows it to work properly, so I
suspect JetBrains definitely is involved with the root cause.
These posts on JetBrain's community discuss various issues with JetBrains causing
VS 2008 to crash. The first thread discusses it occurring when launching Team
Explorer, and the last post in the thread shows a workaround that one person
used.
http://www.intellij.net/forums/thread.jspa?messageID=5220305�
http://www.intellij.net/forums/thread.jspa?threadID=276450&tstart=15
http://www.intellij.net/forums/thread.jspa?threadID=276582&tstart=30
http://www.intellij.net/forums/thread.jspa?threadID=276594&tstart=30
"
My question to the JetBrains: Any ways to fix it? Can you give me any phone, email address of person who can give me reply or I can work with? Please use my email.
Hello Vasily,
Thank you very much for so detailed information! This is the first time we
probably have something we can get our hands on and I will fire my WinDbg
on this tomorrow. If you can attach WinDbg and get crashdump as well as logs,
that would be extremely helpful. Unfortunately, we don't have access to Microsoft
crashdumps. You can send them directly to me, orangy at jetbrains com.
Sincerely,
Ilya Ryzhenkov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
V> We are expecting the same problem with the same environment
V> (VS2008+ReSharper 4.0 + Windows XP or Win 2003 server).
V>
V> I've worked with Microsoft on that problem and reply is:
V>
V> We had an incident#SRX080723600071 with the same description and
V> results of our investigation:
V>
V> It looks like there are components running in a different appdomain
V> (possibly a webservice call). We see where JScript
V>
V> is calling into some object which eventually calls into
V> JetBrains.UI.Interop.WindowsHook.CoreHookProc. It appears that
V> JetBrains have set a hook on some thread to watch messages being
V> dispatched to it. We can't tell what thread from this output, but I
V> suspect it would be the main UI thread since this is in the
V> JetBrains.UI namespace. We see where that calls
V> JetBrains.UI.Interop.Win32Declarations.CallNextHookEx, which is
V> likely calling into User32!CallNextHookEx. In any case, this appears
V> to end up resulting in a System.SecurityException. It's unclear
V> whether this is handled or not. Please check with JetBrains whether
V> they expect to see these types of exceptions.
V>
V> The JetBrains code is involved with the managed exceptions. We know
V> that Visual Studio is crashing because our ole32!CCliModalLoop
V> instance appears to be released. We don't have any direct evidence
V> from the dump that Jetbrains caused that, but we do know that
V> removing JetBrains from the IDE allows it to work properly, so I
V> suspect JetBrains definitely is involved with the root cause.
V>
V> These posts on JetBrain's community discuss various issues with
V> JetBrains causing VS 2008 to crash. The first thread discusses it
V> occurring when launching Team Explorer, and the last post in the
V> thread shows a workaround that one person used.
V>
V> http://www.intellij.net/forums/thread.jspa?messageID=5220305�
V> http://www.intellij.net/forums/thread.jspa?threadID=276450&tstart=15
V> http://www.intellij.net/forums/thread.jspa?threadID=276582&tstart=30
V> http://www.intellij.net/forums/thread.jspa?threadID=276594&tstart=30
V> "
V>
V> My question to the JetBrains: Any ways to fix it? Can you give me
V> any phone, email address of person who can give me reply or I can
V> work with? Please use my email.
V>