Visual Studio 2012, VS 2012 Command Prompt, VS 2010 Command Prompt, and a C++ console application compiled in 64-bit with VS 2012 are all reading an out of date instance of various registry keys. Each application (i.e. VS 2012, the command prompts, and the compiled app) all seem to have their own version of this out of date registry. Below are the symptoms I'm seeing and my various attempts to fix it.
I've both added new registry entries and updated the data in existing ones and all appear updated in HKLM\Software\ viewing them with RegEdit and using 'reg query ' in a normal console window.
Using the VS Command Prompt I perform the same query and get registry entries prior to my updates. If I open up a VS 2012 command prompt and perform edits using command line arguments the registry for that VS 2012 command prompt is now different than the registry read by the VS 2010 command prompt. It is also different from the VS 2012 IDE and the application built from VS 2012. They seem to have their own instances of whatever version of the registry they are reading from.
Finally, I opened up the Visual Studio 2012 command prompt and typed Regedit. It opened up RegEdit and it was viewing the old registry! All of the stale values within HKLM\Software\ were present - a seemingly completely separate version of the registry. Where is it getting this from?
My environment: Windows 7 Enterprise, VS 2012 Ultimate, console application built in 64-bit.
It should be noted that I have not made any major environment changes that I recollect and this is a new issue on my previously working development system. My colleagues have the same/similar environment and hardware setups with the same code base and have never encountered or seen this issue.
Things I've tried.
The almighty reboot
Uninstalling / Re-installing VS Studio 2012 as well as wiping out my code base, pulling it fresh and rebuilding (brute force I know...).
Checking the Registry for Wow6432Node keys to see if the reads/writes are getting redirected (I do not have a HKLM\Software\Wow6432Node and no other instances of that key have the old stale data or much else for that matter)
Searching the entire registry for the stale keys/values/data I'm seeing (not found anywhere)
Turning off virtualization using 'reg FLAGS hklm\software\ SET DONT_VIRTUALIZE DONT_SILENT_FAIL RECURSE_FLAG' as well as variations of this with one flag at a time.
Writing and debugging a unit test to try and determine anything.
VS 2012 safe mode
VS 2012 logging to see if the log file could shed any light on the problem.
Cursing (quietly because I'm at work)
Bribes (my workstation has yet to respond to these attempts)
Any help would be greatly appreciated. I'm close performing a clean Windows installation on my workstation but would rather save myself the time and trouble of setting everything up again :)
Related
I'm afraid I know the answer to this already, but I'm hoping someone can point me in a better direction. I just finished developing a large ETL project using VS2013. My dev machine has SQL Server 2012 installed, and everything works perfectly executing from within VS. However, I just went to deploy the project to another device running SQL Server 2012, and got a version error.
I thought if I could open the solution in VS2012, the packages might recompile correctly. However, I can't open them in VS2012 due to version errors again ("version can't be lower than current version" error). I'm pissed because everything worked fine in development with the VS2013/SQL2012 combo, but now suddenly it's no good?!?
Can someone please help me figure out how to get these packages downgraded to work with VS2012/SQL2012? There are only a few script tasks involved if that makes a difference. Mostly it's just basic SSIS tasks and data flows.
Thanks.
I found a workaround how you can "downgrade" your SSIS 2014 packages to SSIS 2012. I wrote it on my blog here:
http://vaniecastro.com/2015/02/26/how-to-downgrade-sql-server-integration-services-2014-packages-to-2012/
The idea is that you need to manually modify the XML file, change the PackageFormatVersion and replace ExecutableType property and componentClassID attribute values to use the DTSX2 Version 2012/01 values instead of the DTSX2 Version 2014/01 ones.
You can try using Visual Studio 2015 SSDT Preview. This now allows you to choose which version of SQL Server you want to target, including SQL Server 2012. I successfully downgraded my packages from VS 2013 / SQL Server 2014 to SQL Server 2012 this way.
https://msdn.microsoft.com/en-us/mt429383.aspx
Once the shell is installed, go to the Project menu=>Project Properties=>Configuration Properties=>TargetServerVersion and choose 2012.
When I run command line application (executable generated using visual studio 2008) on non development windows 7 machine it gives following run time error "application has requested run time to terminate in unusual way. Please contact application support team for more information". It runs fine on a development machine.
With VS 2005 and VS 2008, Visual C++ used a side-by-side versioning scheme that requires manifest entries embeddded in the EXE to really work correctly in all cases. It's possible you are dealing with one of these. See these articles for details on debugging these side-by-side issues.
Diagnosing SideBySide failures
Part 1: Troubleshooting VC++ Side by Side Problems
Part 2: Troubleshooting VC++ Side by Side Problems
Note that with VS 2010 and later, Visual C++ no longer uses this side-by-side scheme. That said, there are still lots of reasons to use embedded manifests anyhow. See this article.
Everything had beed working great, but suddenly something happened and every time I try to open any web-based project (either MVC or just 'Open Web Site', any others are just fine), Visual Studio 2012 crashes with Windows environment message:
MyProject - Microsoft Visual Studio (Administrator): devenv.exe - System error
Exception Processing Message 0xc0000005 Parameters 0x000007FEFD4A718C 0x000007FEFD4A718C 0x000007FEFD4A718C 0x000007FEFD4A718C
ОК
I did not notice exact moment when it stopped working. And obviously I have different extensions etc. But I believe, I did not install any big soft these days.
I've installed Windows 8 though, but separatly - on separate volume to try it. Theoretically, it might affect my situation, but I don't know how is that possible - at least I don't know any explanations.
I've tried to refresh Visual Studio 2012 installation, even removed and installed it again.
However, at the same time, I have Visual Studio 2010 previously installed, and it opens web-based projects without any problems.
Mentioned error message above is, as I understand, some generic error message - googling did not help on its recognizing, so don't know what to do - don't really want to reinstall Windows because of that.
Does anyone have any thoughts? Thanks!
I really don't know what was the cause of the problem, but after all other tries I've applied all pending updates of Windows Update service and everything works well after that.
I am getting the following error when starting Visual Studio 2012 as unprivileged user:
An error has occurred while trying to access the log file. Logging may not function properly.
A casual web search showed that the issue used to exist with VMware 6 beta, back in 2006. I also found one other user who experiences the same in a more recent VS version (2008) and it started only recently.
The title of the message box indicates that this comes from VMware. I have VMware 9 Workstation installed. The problem could be related to system updates or the update 2012.2 CTP and hasn't gone with the final 2012.2 update package.
The question:
How can I get rid of the error without actually disabling the VMDebugger add-in?
Temporary workaround:
There is a workaround, disabling VMDebugger in the "Add-in Manager". However, it even seems that unprivileged users are unable to successfully disable it. I had to start VS as admin (I am using SuRun for the purpose) to disable it and the error not reappearing upon next start of the IDE.
I had the exact same problem, this is how I solved it.
I monitored devenv.exe using procmon to find the log path, on my computer it was: %TEMP%\vmware-username
I checked the permissions on the log directory, and discovered that my user had no access - neither read nor write! I gave myself full access and deleted the old log files. That solved it for me.
I think this happened because UAC was disabled when I installed VS and VMware.
In Visual Studio, go to the menubar to VMWARE / About VMWare Virtual Debugger; the Debugger log file will be listed there, e.g. C:\Users\Phil\AppData\Local\Temp\vmware-Phil\vmware-vsid-1.log
Give your user full access to that file.
(This solution was for Visual Studio 2013, VMware Workstation 11.1.2, Windows 8.1.)
The fastest and easiest way to solve is...
1. Locate the folder %temp%\vmware-{username}
2. Delete this folder. The folder will be created by opening the Visual Studio.
Note: You need to open the Visual Studio without admin rights to resolve the issue!
Background: Mostly this happens if you use the VMware debugger plugin the first time under admin rights (because your app may need this right to run properly). This creates the folder under admin rights with the admin permissions. Everytime you open the Visual Studio with admin rights, you have no problems.
Examples
Windows: C:\Documents and Settings\<username>\Local Settings\Temp\vmware-<username>-<PID>.log
Linux: /tmp/vmware-<username>/ui-<PID>.log
This post helped me
The fastest and easiest way to solve is...
1. Locate the folder %temp%\vmware-{username}
Go in windows+R %temp% , delete all , ready !
I followed the instructions in this link: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx to install the remote debugger (2012) on my server where the application is running in hope to debug it remotely from my dev machine running visual studio 2012.
I cannot even get as far as viewing the list of processes to attach to on the remote machine. I keep getting "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named [name]. Invalid access to memory location".
I have managed to successfully connect a few times but then the attach fails immediately then I cannot connect again.
This is causing huge issues for me as I cannot remote debug anything. I must be missing something glaring. Please someone give me a solution.
I've found the only way to correct this is by restarting Visual Studio.
Worked for me. I found it at this blog post about invalid access and remote debugging.
It turns out the one thing I missed was to tell Visual Studio where to find the .pdb symbols relating to the remote process. To do this go to Tools -> Options -> Debugging then in the Symbol (.pdb) locations add the remote location to the pdb files.
To clarify, I was attaching fine but could not break into code. Now I can. Be aware though that there are other hurdles before you get to my stage where I was attaching to the process successfully but could not catch a breakpoint.
I recently had someone else report this and debugged the issue on their machine. The "Invalid access to memory location" errors are due to an issue in Windows, it can be addressed with this hotfix.
I have had this problem in VS 2012, 2013, 2015 and 2017. Based on other answers it is likely that the problem is related to running a 32 bit version of Visual Studio on a 64 bit PC. Sometimes, as others have recommended, restarting Visual Studio fixes the problem but the best solution I've found so far is to start Visual Studio without a solution, open Debug -> Attach to Process, change the Connection Target to the remove server and wait for the process list to load. Then Cancel, do not attach yet. Load your desired solution and then come back to Attach to Process and the remote process list will still be loaded. Connect to your desired process and everything should work properly from then on.