Edit 1: Uninstalled & Reinstalled
Edit 2: Same problem. Seriously? Yes.
I am having a problem with msvb7.dll eating 50%+ cpu on my dual core system. This usually lasts 10-30 seconds or so, during which time the IDE is non-responsive.
This occurs when I do pretty much anything in the text editor, and can be replicated by simply adding blank lines to a function, and then deleting them. Or pasting some code. Or... lotsa stuff.
SP1 installed
I had DevExpress' refactor/coderush, components, and codeit.right installed, but have removed all 3 of them.
(I had installed the latest version of Refactor Pro! (9.3.4), perhaps the day before)
I have tried a VS.NET Repair.
There is a kb that referenced some cpu destroying with vb, but it was included in SP1
Also:
The solution consists of ~30 VB projects and 2 C# projects
8 other developers aren't having any issues with this (or at least not the SAME issues, we all have em)
Clean get from TFS was done
Project builds properly, can can even debug.
This doesn't seem to happen on really small solutions, but perhaps it does and it just goes away super quick.
Any clues at all as to what might be causing this, or how to fix it? I REALLY don't want to lose another day uninstalling and reinstalling and patching and so on =) If that even fixes it.
Edit looking at these two hotfixes. Applied 957912, the first one
KB957912: Updates for Visual Studio 2008 SP1 debugging and breakpoints
KB967631: When you debug in Visual Studio 2008 Service Pack 1, more breakpoints are generated unexpectedly, or the IDE crashes or becomes unresponsive for about 15 seconds
Here is the stack trace (process explorer) that I get from the threads window when the msvb7.dll is churning.
--- title in process explorer [threads] tab for process --------
cpu:49.28% cswitch delta: 300 to 3500 startaddress: [msvb7.dll+0x4218c]
msvb7.dll version: 9.0.30729.1
--- actual stack trace -------
ntkrnlpa.exe!KiUnexpectedInterrupt+0x121
ntkrnlpa.exe!ZwYieldExecution+0x1c56
ntkrnlpa.exe!KiDispatchInterrupt+0x72e
NDIS.sys!NdisFreeToBlockPool+0x15e1
// shortened stack trace. all of these are from msvb7,
msvb7.dll+0x46ce7 <- 0x2676a <- 0x2698e <- 0x38031 <- 0x2659f <- 0x26644
msvb7.dll+0x25f29 <- 0x2ac7a <- 0x27522 <- 0x274a0 <- 0x2b5ce <- 0x2b6e4
msvb7.dll+0x67d0a <- 0x68551 <- 0x6817b <- 0x681f0 <- 0x67c38 <- 0x65fa8
msvb7.dll+0x666c6 <- 0x6672c <- 0x6673d <- 0x6677c <- 0x667b4 <- 0x63c77
msvb7.dll+0x63e97 <- 0x42c3a <- 0x42bc1 <- 0x41bd7
kernel32.dll!GetModuleFileNameA+0x1b4
This is the list of stuff from "copy info" in help->about, shortened to a resonable length.
Microsoft Visual Studio 2008 | Version 9.0.30729.1 SP
Microsoft Visual Studio 2008 Professional Edition - ENU Service Pack 1 (KB945140) KB945140
Microsoft .NET Framework | Version 3.5 SP1
Microsoft Visual Basic 2008
Microsoft Visual C# 2008
Microsoft Visual F# for Visual Studio 2008
Microsoft Visual Studio 2008 Team Explorer | Version 9.0.30729.1
Microsoft Visual Studio 2008 Tools for Office
Microsoft Visual Web Developer 2008
Hotfix for Microsoft Visual Studio 2008 Professional Edition - ENU
KB944899, KB945282, KB946040, KB946308, KB946344, KB946581, KB947171
KB947173, KB947180, KB947540, KB947789, KB948127, KB946260, KB946458, KB948816
Microsoft Recipe Framework Package 8.0
Process Editor WIT Designer 1.4.0.0
Process Editor for Microsoft Visual Studio Team Foundation Server, Version 1.4.0.0
tangible T4 Editor 9.0
tangible T4 Text Template Editor - T4 Editor
tangibleprojectsystem 1.0
Team Foundation Server Power Tools October 2008
SQL Prompt 4.0 (disabled)
Use Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) and trace the activity of Visual Studio when it exhibits this behavior. I have done this many times before with great success.
I am actually monitoring Excel on startup to determine why Excel is having problems with a VSTO Add-in. It turns out Excel is trying to also load a previous version, so I have two add-ins loaded. I figured this out in less that a minute. Without Process Explorer I might have been troubleshooting for hours or days.
I've seen something similar happen when you have a circular reference in a specific way in a class. It's trying to show intellisense and ends up in an infinite loop trying to build the list. I don't remember the exact circumstances now, though.
Given up and wiped VS 2008 & all supporting software. Reinstalling now. It is fun to debug, but I had to cancel a meeting this morning because I couldn't get anything going.
If I get a job at MS then I'll look into it further... but this one is just too hard for
me and my limp debugging skills leftover from years doing .net ;)
DOH! Reinstalled and it is still broke! I may actually have to solve this :(
#amissico: thanks, i had forgotten about that completely.
The problem is somewhere in the parsing thread, and I can't work out how to pinpoint what it is doing wrong. I see lots of FS activity, but nothing that I can identify as wierd. It just keeps building temp files (all the same name?) It just looks like it is doing everything everytime, the slow way. I don't know what it should look like, though.
Startup is fine, this is mostly happening when I edit files. It just starts chewing for intellisense, it appears, but why it takes so long is wierd.
Related
I have a medium size project coded in vb.net using latest version of 2017 visual studio.
The problem that I am having right now is that when I edit a textbox say txtCarType to txtCarType2 it takes about 15 seconds to process.
I am also having the same issue with labels or renaming any control. how can I fix this issue this lagging its killing productivity.
Visual Studio is trying to be generous and refactor the new name throughout your project. This indeed helps as if it does not refactor you could be left with some errors. When you rename controls a refactor window pops up as it churns through files to refactor the name through-out the whole project. This indeed can be dreadful, irritating and possibly a long process depending on your solution/projects.
Please give this a shot...
Tools --> Options --> Windows Forms Designer (expand node)
General --> Refactoring (set "Enable Refactoring on Rename" to False)
Hope this helps!
Off the top of my head it could be one of 2 things.
It's just running a bit slower because of the size of your application. Trying to sort through all that data takes time, so it's just gonna take a few seconds to find what it needs and change it.
Refactoring for all references to the object in your code to prevent errors.
In Visual Studio 2013, I used the Code Analysis window to provide reports to both the Development and Management teams.
In Visual Studio 2015 Enterprise RTM, these errors have returned to the error window and I can no longer just see CA issues for a single project, or filter them by type.
Is there a way to bring the Code Analysis window back?
Visual Studio Code Analysis has been merged with Intellisense and can now be viewed from the Error window. When you select "Build+Intellisense" or "Intellisense" your code analysis warnings will show up there. You no longer need to build your solution to see them there.
This is one of the perks of the new Roslyn based editor.
Setting it to Intellisense Only should show you your code Analysis Warnings and on the left there is now an option to select "Entire Solution", "Current Project", "Current Document" or "Open documents".
I personally really like the last option, as it works really well for people wanting to leave the campground cleaner than they found it.
If you add additional analyzers (through a vsix or Nuget), they show up as additional rules for Code Analysis.
You can add the "Category" column:
And then filter by category:
Recently I noticed in my current vb.net project that sometimes (depending on the value), if I enter a double value the editor changes my input, for example:
When I type ...
Dim x As Double = 0.6
...after commiting the line by pressing Enter it becomes:
Dim x As Double = 0.59999999999999998
If I directly undo the action, then it gets reverted back to the original value I typed in. Any future edit in that line will again produce the undesired results.
I'm aware that internally 0.6 is calculated as 0.59999999999999998 so it doesn't make a difference for the running application, but it's very annoying and the strange thing is: this hasn't always happened and, if I create a new project, it doesn't happen there either.
So my questions are: How can I prevent VS from doing this? Why does it happen at all? Why isn't it always like this (previously in my current project or in a new one)?
I'm running 64bit-Windows 8.1 on an Intel CPU - if that has anything to do with it.
Has anyone got any ideas?
EDIT: I'm using Visual Studio 2013 Professional (12.0.31101.00 Update 4) and, yes, the project has been migrated from several earlier VS versions. There are no relevant Add-Ins or extensions installed. Disabling "Pretty Listing" does indeed prevent the problem, but of course then the other highly useful aspects of the option are disabled as well :o(
EDIT2: After the tip leading to "Pretty Listing" I found the following SO article, but there also no solution was found: Visual Studio VB pretty listing settings
Several years ago I had a project where this was happening. As you wrote, the reason for the number is that some numbers can't be represented exactly in a binary floating point variable. More on this here.
My project had been upgraded through several versions of Visual Studio. It was also shared with developers using VS Express.
If I ran into this problem again today I would open and check the project-file manually, or just simply create a new project and re-add the files if I could not quickly locate the problem and the project was small enough.
If you have upgraded the project through multiple versions of Visual Studio like I had, it might be dragging some settings along that are no longer visible in the projects options dialog.
Just as an interesting experiment you could also try to turn off Visual Studio's Pretty Listings to see if that is what is actually changing your code.
I'm kind of new to Visual Studio. I've built a few simple programs in it, but now I'm in the process of rewriting a huge system I wrote in VBA. What is frustrating me is the Error List in VS is only listing errors for one .vb File in my project, lets call that VBFile1. Now, when I work on another vb File, VBFile2, which is in the same project as VBFile1 no red squiggles or errors are listed for VBFile2. I don't understand how this could happen. This is what I've tried/checked:
Filter is set to 'Current Project' and I played around with the other Filter settings but no change.
Checked the Text Editor under Options and according to the research that I've already done it is fine. Plus, I have never changed any of these settings anyway.
Closed and re-opened Visual Studio.
Closed all open files in the Project and still displays the same error list
Close all files except the VBFile2 but still shows the same error list of VBFile1.
I have Visual Studio 2012 Ultimate. I feel like this should be an easy fix...I just am really confused what's going on.
Hope this makes sense!
UPDATE: Excluded from project, VBFile1 and finally errors are listed for VBFile2...why would this be?
I am not sure if it has been fixed in Visual Studio 2012, but there is a Connect Request for Visual Studio 2010 with a resolution of won't fix because of performance issues. The effect your are seeing is because you have exceeded the maximum number of errors for that project (what I am used to seeing is 102 as the threshold), it will not show you anymore till you fix the ones that it has already shown you.
According to this MSDN article, which I found through this SO question the limitation is still there for the IDE but has been removed for the command line compiler.
From above MSDN Link:
Limitless (Command-line) Errors!
This is actually a good thing, let me explain. For performance reasons, the Visual Basic IDE maxes out at 101 errors (with error #102 being “Maximum number of errors exceeded.”) This can make it difficult to estimate the amount of work remaining in certain situations, particularly in upgrade scenarios. We have removed this limit from the command-line compiler in this release, though it still there in the IDE. What this means is if you want to know exactly how many errors there are for a project, just invoke the compiler through msbuild.exe or vbc.exe and you’ll get your answer.
This problem is pretty self explanatory. Here are the details: I'm trying to include freeglut and glew in Visual Studio 2012 on Windows 8. I'm on a 64 bit system, so I thought I needed to put glew32.dll in my 64 bit system folder. I tried that and receive the following error:
"The application was unable to start correctly (0xc000007b). Click OK to close the application."
Which I've interpreted as I'm trying to put a 32 bit dll in the 64 bit folder or vice-versa.
Just for laughs, I tried putting the file in System32, but of course, it just told me the file wasn't on my computer. Any suggestions?
EDIT* May I also add that some of the set up for this was NOT the same as it would have been on Windows 7 or Visual Studio 2010 or earlier. I may have missed something because I kind of winged it using the search function combined with some documentation I found on various websites. (i.e the lib and include folders are no longer in the same place)
EDIT2* I'm sure this can probably be derived, but I want to add it anyway for clarity: If I removed the dependency for glew32.lib and comment out any code using glew.h, the window forms as it should. I don't think my source code is needed seeing as I'm 99% sure this is not a code issue, but if anyone wants to see it, let me know and I'll attach it.