I’m using VB 2019 with the latest updates on 64-bit Windows 10 with the same. In the past few days I’ve started having a 30-40 second delay when loading my code in debug mode. Up until a couple of days ago this only took about 5 seconds. Any ideas what might have happened and/or how I can reduce this delay starting up my code every time I make a change to it?
Windows updated a couple of items each of the last couple of nights, I wonder if any of these have triggered the new behavior.
The reason may be that many files are created during compilation, and the anti-virus tool provided by Microsoft will scan the created files, so the compilation speed is reduced.
You can set a folder whitelist in the Windows Security Center, which is Windows Defender. Files in this folder will not be scanned. Putting my own code warehouse, I will put all my code in a folder, add this folder to the whitelist, it will not be scanned during compilation, which can speed up the compilation speed.
Related
I have a solution written in VB with some C# components. The solution uses some libraries from 2 outside sources. I have been working on this project for several months without issue. I cannot identify anything specific that I did to change my system or configuration. I was just working through the code, transitioning from an old set of library calls to the new library calls. The new library calls require complete rewrite so I change sections of the code and test to that point. Visual Studio 2013 debugger as of Friday morning will no longer recognize or show my local variables in this solution. The only things that appear in the Locals window are under Me. The code does work and I have it writing out to a text log file to confirm the values of variables at certain points, but the debugger has gone blind. When I add any of these local variables to Watch the response is " is not declared. It may be inaccessible due to its protection level."
Steps I've taken so far with no permanent success:
looked online and tried the few matches I found with no success
deleted the bin and obj folders and had the solution rebuild with no
success
recreated solution from scratch, copied over base files and rebuilt
solution and project (which worked for a few hours), until I did a
rebuild project and problem appeared again
updated to pack 5 and no success
I have opened my older projects and checked them. The debugger runs just fine and shows the variables. It is obviously something that happens during the rebuild process.
Any assistance would be greatly appreciated.
Thanks
Update:
Let me try to explain a little more clearly the situation.
I have an application I have built and am selling to some customers. Version 1 is installed and running at several locations. It is written in VB and uses some older COM libraries for a particular integration process.
The vendor is retiring the COM libraries. Their new libraries are in C#.
I created a new copy of my entire application (solution) and imported the new C# libraries. I have been going through and replacing the old code with the code for the new calls.I recompiled the solution and everything ran fine in debug.
The objects used with the new calls are completely different and there is limited documentation so I update a section of code and test to that point. Each time I "Save all Files", rebuild the project and test the changes. Everything worked fine for a few days. On Friday morning I started working on more changes and got an odd error. The system was not getting a proper value for a certain variable. When I went to check it in the WATCH window, debugger said it could not evaluate it. I figured something was hung up so I shut everything down and rebooted my machine. When I tried it again later, the same problem.
After several hours of no success I exited VS, renamed the folder to "OLD" and recreated the solution from the older version. Immediately everything was looking fine. I started making the changes and testing. Each time I did a rebuild, everything looked fine until the last change. Here I am again.
The code works fine up to the point I have updated. The only issue is that the debugger windows are not working correctly. If a variable is declared at the Class level outside the Sub, they can be seen. The only variables the debugger is blind to are the local variables within the running Sub.
I looked for anyone else with this issue and only found a few items. I tried the suggestions but no joy. I am left with having to temporarily define the variables outside the sub so I can see them while debugging.
I am on VS 2013 Update 5.
Do I need to move to VS 2015 to get around this?
Thanks again for your time and assistance.
I am assuming that you haven't changed versions of visual studio since the last time a rebuild worked for you.
recreated solution from scratch, copied over base files and rebuilt solution and project (which worked for a few hours), until I did a rebuild project and problem appeared again
Based on this, you create it from scratch and everything works until you do the rebuild right? But you are copying the base files still and you have new library calls since the last time a rebuild didn't mess up the locals window. So one of those is almost assuredly the culprit.
Since the library calls seem to be the thing that changed based on your post start there. If you go back to the old code and do a rebuild does it fix it? Assuming so, put the library calls back one at a time until it breaks.
If going back to the old code doesn't fix it, create from scratch with the old code and copy over the base files and rebuild. If that fixes it, add new library calls one at a time and rebuild after each until it breaks.
If that doesn't fix it either, then you will need to dig deeper on what else might have changed.
You are copying base files so eliminate those as the problem if you can:
Are you able to use placeholders instead of the base files or something that won't necessarily work as a finished product but that will allow you to debug, rebuild, debug again to see if the problem is related to one of them? Check the dates on the base files and ensure that they haven't changed since the last time a rebuild worked.
Something you could do concurrently could be to have have a colleague do a rebuild on their machine and see if the same issue comes up for them. It would (almost) completely eliminate the possibility that it is a configuration / program corruption issue on yours. Alternately, there are some free vb.net compilers online that you can upload files and code to. I'm not sure if that would be practical for you (due to the components of your program and/or sensitivity of the data) or not and haven't ever tried any where there is C# code in there but I wouldn't think that would be an issue.
I've been using Visual Studio 2010 for years now. I have a fairly complex VB.net project that I routinely make changes to. Recently, whenever I'm making changes in debug mode, it throws a System.InvalidProgramException - Common Language Runtime detected an invalid program error which forces me to stop running the program and then restart it again after I've saved my changes.
This issue only happens when I make changes to a Sub or Function which is called by another Sub or Function. For example, if I make a change to a button click event, it's fine, but if I make a change to a function that button calls, it errors.
A change as simple as adding blank lines in my code will cause this to happen. No code change at all...just literally hitting return to add blank lines between code lines.
I installed Visual Studio 2013 thinking it would solve this. It does not. I still get the same errors.
I tried moving my project files to a different HDD, I still get the same errors.
I thought maybe I have corrupt memory, so I ran a full checkdisk and defrag but I still get the same errors.
I've read where this error may happen with very large procedures or projects with lots of variables (although I thought this was fixed in newer .NET versions) so I've cleaned up my code. The largest Module has 30k lines.
The workaround is to stop the project running, save my changes and then restart it...however, that takes time because my program has to reinitialize everything when it runs, so I'd prefer to be able to make changes while debugging.
Also, I have .NET framework 4.5 installed
Update: I loaded up a backup of my code from a month ago and it runs fine...so apparently some recent changes I've made are causing this error. Once I figure out what's changed, I'll update this just for future reference in case anyone else runs into the same issue.
As you are working on the IDE, suddenly it has no reaction, the whole IDE become inactive and can not operate on it, but with high CPU usage, If you kill the process from Windows Task Manager, after it launched, all modified lost since your last edit. This problem occurs every now and then.
My environments:
Windows 7, Intel i7, 16GB RAM, IDEA 12.1.6 with auto save enabled.
Did anyone come across this problem before, it's to bad as my changes lost and i have to rewrite it after restarted.
You'll want to upgrade to v12.1.6 as 12.1.5 had a major bug in it that was fixed in 12.1.6. The bug prevented compiling of code in some circumstances. 12.1.6 was released only a few days after 12.1.5. That may not be the cause of your issue, but is still good advice.
Other than that, the 12.1.x line has been very stable. I think your issue is an isolated case as I have not seen any mention of it in the IntelliJ IDEA forums or here. Often times, such deadlocks are caused by third party plug-ins. Take a look in the logs (Help > Show Log) to see if it has any information that explains the hang. Also, if IDEA becomes non responsive, it automatically logs thread dumps in the log directory. Those may have some information.
If you experience the issue again, you may want to disable any third-party plug-ins to see if that resolves it. If it happens frequently, you can take a CPU Snapshot as described in this document and submit it to the JetBrains.
Lastly, I recommend you tweak the following setting: File > Settings > [IDE Settings] > General > Save files automatically if application is idle for x sec." Set it to 15 or 30 seconds. (You don't want to go too low). This will help reduce any loss of work in the event of a hang (which after 10 years of daily IDEA use I can attest to as being very rare.)
This is the same question as on turn off FTH but on Windows8 so maybe there's a different answer. I have tried ALL the suggestions there and it still won't go away. I'm trying to debug a 32 bit program on 64 bit Windows Pro 8. I've tried setting all the registry entries (and rebooting); these normally only exist in the 64 bit part but I added them to the 32 bit part as well. I've tried renaming the acxtrnal.dll file (both 32 & 64 bit versions). I've tried running the rundll32 suggestion given. None of these have stopped FTH running and destroying my program performance - an operation which took 5 seconds is now taking several minutes.
The only way I have found to get around it is to rename both the visual studio and my program executables - which I will have to do again when it next starts crashing (which it will - I'm doing development!!).
Any ideas?
To disable it for a single application
Go to the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER versions of
Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers\your_application.exe and
delete the FaultTolerantHeap entry.
or visit this link
Here
I am attempting to perform a stackwalk with Xperf, using a batch file similar to the one listed at Getting the symbols with xperf.
I launch XperfView, confirm the symbol path is correct, and then load the symbols. However, when I attempt to open a summary table on a selected portion (5 seconds or so) of the "CPU Sampling by CPU" graph, the Performance Analyzer hangs (not responding) for a long time (hours).
I left it running last night, and when I came in this morning the Summary Table had finally loaded, containing results as expected... I had thought perhaps it was just performing an initial download to cache the symbols to C:\symbols, but a repeat test this morning has similar problems (hang for 1 hr 15 minutes at this point).
WPT (xperf, xperfview, WPA) doesn't ship with dbghelp.dll and symsrv.dll. That means that, depending on what is in your path you may get:
Fast symbol loading
Symbol loading that takes up to 150x longer
No symbol loading at all.
The solution is to copy a known-good version of these DLLs into the WPT install directory. For more details see this post:
http://randomascii.wordpress.com/2012/10/04/xperf-symbol-loading-pitfalls/
In his post , Bruce Dawson speculates that there is an issue with dbghelp.dll and/or symsrv.dll in WPT as shipped in the current SDK. He suggesting replacing those with the ones either from Visual Studio 2010, or from Debugging Tools for Windows (i.e. WinDbg). Worked for me...
Have you set up symcache something like this
SRV*c:\dev\symbols*http://msdl.microsoft.com/download/symbols
The symcache would cache the symbols locally. I usually have my _NT_SYMBOL_PATH environment variable with the above information.
HTH