Related
Our previous development systems used Windows XP and Windows 7. Debugging C++ DLLs from Visual Studio worked great.
A recent move to Windows 10 has resulted in an annoying problem. We can debug once (using F5), but the 2nd time results in a linker error:
MyProg fatal error LNK1201: error writing to program database 'MyProg.pdb'
Trying to delete the .pdb manually in Explorer while Visual Studio is still open results in the error:
The action can't be completed because the file is open in devenv.exe
It doesn't matter whether you hit a breakpoint or not. Just start debugging once results in the problem. Re-starting Visual Studio resolves the issue (in the sense that you can debug once, but then you get the problem again).
If relevant:
x86 Visual Studio 2003.NET
targeting another x86 application
x64 Windows 10 Pro v1803
After hunting around for several hours some related, but unanswered, questions were found. Following suggestions in this MSDN article, along with some debugging of my own, this solution works:
Download FreePDB, a script written by MSDN user Toni76 (thanks Toni!)
Copy this script to a local folder (say C:\Apps\FreeDPB)
Download the latest version of SysInternals tool Handle (currently v4.21)
Copy handle.exe to C:\Apps\FreeDPB
NB! From the command line, run handle /? once. This is to agree the EULA. The script will not work if you skip this step!
Open Visual Studio, then Project > Properties > Build Events > Pre-Build Event
Set Command Line to C:\Apps\FreeDPB\freepdb $(ProjectName)
Set Description to Delete lock on PDB
...and now you don't need to restart Visual Studio to debug a 2nd time!
From comments, this works with multiple versions of Visual Studio on multiple versions of Windows.
Update
A more radical solution is described here which involves replacing a core Visual Studio DLL (NatDbgDE.dll). This solution only works for Visual Studio 2003 SP1, though.
In my case it was due to "Process Explorer" program, which was open alongside with my Visual Studio(I used it to check some properties of the exe I've created). After closing it problem solved.
visual studio 2017 community.exe won't run after extracting to the temp.
OS: windows 10 x64bit
Setup : community version
in the temp folder bootstrapper log says,
Beginning of the log. Start Time: 3/26/2017 1:14:54 AM
VisualStudio Bootstrapper:3/26/2017 1:14:54 AM: Current Optin root path does not exists
VisualStudio Bootstrapper:3/26/2017 1:14:55 AM: Commandline arguments =
and the dd_vs_community_decompression_log says
[3/26/2017, 11:17:47] === Logging started: 2017/03/26 11:17:47 ===
[3/26/2017, 11:17:47] Executable: C:\Users\Sameera\Downloads\Programs\vs_community.exe v15.0.26228.0
[3/26/2017, 11:17:47] --- logging level: standard ---
[3/26/2017, 11:17:47] Directory 'C:\Users\Sameera\AppData\Local\Temp\4ceac4b7b9cd9fdf2489526c66\' has been selected for file extraction
[3/26/2017, 11:17:48] Extracting files to: C:\Users\Sameera\AppData\Local\Temp\4ceac4b7b9cd9fdf2489526c66\
[3/26/2017, 11:17:48] Extraction took 360 milliseconds
[3/26/2017, 11:17:48] Executing extracted package: 'vs_bootstrapper_d15\vs_setup_bootstrapper.exe ' with commandline ' '
[3/26/2017, 11:18:10] The entire Box execution exiting with result code: 0x0
[3/26/2017, 11:18:10] Launched extracted application exiting with result code: 0xc000000d
[3/26/2017, 11:18:10] === Logging stopped: 2017/03/26 11:18:10 ===
can't find proper solution..
I had this problem too. SHClark's answer didn't work for me. I figured out myself what was causing the problem on my computer: Mirekusoft Install Monitor. I disabled both its services and that solved the problem. (I guess that's not an extremely likely program for someone to have running, but it could be a problem common to install monitors in general?)
I also heard from someone on the Visual Studio Community forum that RivaTunerStatistics (used for gaming) can cause this problem too.
One of my co-workers encountered the same problem. We spent 4 hours searching for solutions, uninstalling VS and other software that we thought might be the culprit.
In the end, THIS LINK helped us figure it out. The problem is somehow explained there and is linked to NODE_OPTIONS variable. If you have that variable set, remove it then restart your computer. This solved his problem.
Configuration:
Widows 10, Visual Studio 2017 Enterprise.
I hope this helps you
I was able to resolve my problem after 4 days of troubleshooting with Microsoft support. I'm developing on a Dell laptop and the support technician believes one of the Dell services was causing issues with the winmgmt service.
Below is a command that failed to run. Then after making sure we had an OS restore point saved, we issued the /resetRepository command. After that, the VS 2017 Pro installer was able to execute without error.
EDIT: Adding the exact steps and code sample below:
Step 1: Create a Windows system restore point.
Step 2: From the command prompt with administrative rights or elevated privileges, execute the following command: net stop winmgmt
Step 3: Open a Windows Explorer and locate the path to C:\windows\system32\WBEM\ folder and rename the Repository folder to something else like RepositoryOLD (right click and choose 'Rename Folder').
Step 4: restart the computer
Step 5: From the command prompt with administrative rights or elevated privileges, execute the following command: net stop winmgmt
C:\>net stop winmgmt
The Windows Management Instrumentation service is stopping.
The Windows Management Instrumentation service could not be stopped.
Step 6: From the command prompt with administrative rights or elevated privileges, execute the following command: winmgmt /resetRepository
C:\>winmgmt /resetRepository
WMI repository has been reset
Step 7: restart the computer.
Hope this helps anyone with a similar Visual Studio 2017 installer issue.
Copy vs_community.exe to a USB and run. It will work.
I had the same (or similar) problem. I couldn't update VS2017, either from within the program or by trying to run the installer.
The web page at https://learn.microsoft.com/en-us/visualstudio/install/troubleshooting-installation-issues had instructions that resolved the problem. For me, deleting the 'Installer' directory and then retrying the installation resolved the problem.
Try deleting this folder C:\Program Files (x86)\Microsoft Visual Studio\.
Restart the install.
Note for others with installer problems for Visual Studio 2017/2019/vNext
Before messing with your system FIRST TRY CLOSING EVERY OTHER PROGRAM.
Sounds silly, i know! But I almost missed inhahe's answer mentioning that RivaTuner could cause problems. Closing that caused it to start working instantly.
TL;DR: Close all other programs like you always ignore in installation instructions :)
Try to stop MSI AfterBurner. Worked for me.
It's the same answer as in question visual studio 2017 install break : it not get start just in case you don't observe the other question.
I had the same Problem on two different Pc's (both win10) and the only thing that worked for me, was reinstalling Windows's and rerun the visual studio installer. I know, that's not a good, fast or easy solution, but it works.
I have been having this issue all day and MS support were not able to help. To solve my issue, I updated my video driver to the latest version (I was intentionally using an old driver as the new versions don't support my monitor resolution). The visual studio installer must use a GUI tech not supported by my older card and just fails before the installer GUI loads. The same issue happened with the older, offline installers for older versions such as VS2013.
I had the same issue, the fix is: go to reigonal settings from control panel, then on the administrative tab select (or if selected reselect) current language for non-unicode programs. than try again.
I had the same problem. Here is my solution:
right click vs installer, extract with winrar.
go to extracted folder.
run: vs_setup_bootstrapper.exe
This worked for me :)
I had the same problem and the problem was my user name containing both space and a non ascii character (Olcay Ertaş). I have moved the installer to my root folder and it worked. This is probably the reason why #oğuzhan-türk's solution is also working.
I had the same problem also (with a Dell labtop) and SHClark's didn't work for me.
Here is what I did:
I used the command line to create a local cache of the files you need to complete an offline install
[ctrl] [shift] [enter] for the cmd prompt to run as admin
1) typed
d:\vs_community.exe --layout h:\vs2017layout --add Microsoft.VisualStudio.Workload.NativeDesktop --includeRecommended --lang en-US
once it was done downloading to h:\vs2017layout,
2)
opened h:\vs2017layout\vs_setup.exe
finally got it to open after extracting but ran into this error:
The name of the file cannot be resolved by the system
so I created a link for the c:\ProgramData\Microsoft\Visual Studio folder using the following command at windows cmd promt:
mklink /D "C:\ProgramData\Microsoft\VisualStudio" "g:\ProgramData\Microsoft\VisualStudio"
It worked after that. Not sure if the second error was related to the first. Hope this helps.
If you have Win8 you needed to update your system to 8.1 ver. and restart your computer.
I had this problem. Turned out there was an old, failed installation on the drive. I had to go to Control Panel->Add/Remove Programs and remove Visual Studio Install Tool. After that the installer worked fine.
Faced the same problem with Visual Studio 2019, but I think version doesn't matter here. This thread helped me: https://developercommunity.visualstudio.com/content/problem/326811/vs-community-installer-not-running-working.html.
The reason was in somehow corrupted .NET files.
Actions applied:
deleted all apps with "Microsoft .NET" in name using https://support.microsoft.com/ru-ru/help/17588/windows-fix-problems-that-block-programs-being-installed-or-removed
downloaded and installed latest version of .NET Framework Runtime (not .NET Core Runtime) from https://dotnet.microsoft.com/download, in my case it was version 4.8
restarted PC
This helped me.
Nothing worked for me here however i was able to find out that there was an error with the main.js file that he couldn't find the temp folder. so i looked up the environment variables and indeed for my current user TEMP was not set resp. empty. i copied the default temp value(%SystemRoot%\TEMP) for all users to my current user TEMP variable and afterwards everything worked
I have lost a lot of time to solve it. By me, it was an error in machine.config, which I made 2 weeks ago. I have found it only because I have tried to uninstall the JetBrains too. And there was an error too , but with a log, where I could see it.
After search during days and didn't work...
I tried uninstall all .NET frameworks and it works!
I have tried all the answers provided so far and none of them worked for me.
What I did after 2 days of searching for issues online and google-ing, as I have started Windows Event Viewer and googled the error that was logged in the Event Viewer at the time of Bootstrapper crash.
The problem was somewhat similar to #inhanes problem above. It turned out to be the Fresco Logic Driver installation that was causing the issue. I have deleted the driver (add or remove programs -> uninstall) and the damn thing worked.
By the way, this driver is written for USB3.0->HDMI converter.
Anyway, guys and girls: Event Viewer which is a built-in Windows logger can be helpful. :) Now I can just leave in peace and develop my stuff.
I need to build a c++ program in Visual Studio on Windows every 24 hours (I belive this is called a kron job?), and then send an email if it fails. I can't download any software on this machine, so I think I will have to make do with what Windows XP and visual studio has to offer.
I found a VBScript online that sends an e mail, which works fine. Now I need to automate the build.
I though about writing the thing on vbs and setting it in schedueled tasks to run once a day. I don't have any experience with VBs.
Is this a good way of solvig this? Any better ides?
Thanks!
You can use devenv.exe to build a solution or a project.
devenv.exe has several command line switches that could be used to start a build.
For example, to build a Release configuration of a solution file called myworkspace.sln you would do the following - devenv.exe myworkspace.sln /build Release.
Here is the list of command line arguments supported by devenv.exe -
http://msdn.microsoft.com/en-us/library/xee0c8y7(v=vs.80).aspx
For the recurring task to be run every 24 hours, use the Windows Task Scheduler to create a recurring task which runs the devenv.exe command line shown above.
Task scheduler can be found in the Administrative Tools menu or you can run the command taskschd.msc.
I have been using NuGet for quite some time on a particular PC. Now, I created a new project in VS2010 (it's an MVC 4 Beta project using the Single Page App template if that matters). When I select
Tools / Library Package Manager / Package Manager Console
The console window opens but displays the error:
File C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\IDE\Extensions\Microsoft Corporation\NuGet Package Manager\1.7.30402.9028\Modules\NuGet\profile.ps1 cannot be loaded
because the execution of scripts is disabled on this system. Please
see "get-help about_signing" for more details.
However, other projects can still open and use Package Manager Console.
In each case, VS2010 is running as the same user.
If I open a command prompt (using the same account under which VS2010 is running), start PowerShell, and enter the command
Get-ExecutionPolicy
PowerShell returns
Restricted
My understanding based on a Scott Hanselman blog is that scripts should not run at all if the ExecutionPolicy is restricted.
Why are existing projects able to use the Package Manager Console while a new one is not?
Update: Changing the ExecutionPolicy to AllSigned and restarting VS2010 solves the immediate problem, but my main question is why the other projects were able to bypass the established ExecutionPolicy. VS2010 is not running as an administrator.
I experienced the same problem and solved it by:
Opening Powershell as an Administrator
Entering the following command "Set-ExecutionPolicy RemoteSigned"
Restart Visual Studio and the Package Manager Console worked as expected
It is important to note however that Powershell will give you a warning
"The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose you to the security risks described in the about_Execution_Policies help topic. Do you want to change the execution policy?"
And should be careful of enabling this feature and should read more information in the help topics about the security risks.
In addition to Murries' answer, I found jellonek's post (on another thread) helpful. You might have to change the permissions on a different version of PowerShell (32-bit and 64-bit versions require separate permissions).
From How to Tell if PowerShell is 32-bit or 64-bit:
64-bit PowerShell Path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
32-bit PowerShell Path: C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
Also, BOTH of these should work:
Set-ExecutionPolicy RemoteSigned
Set-ExecutionPolicy Unrestricted
Another way to fix this is by merging a Regedit file with the following content:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]
"ExecutionPolicy"="Unrestricted"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell]
"ExecutionPolicy"="Unrestricted"
(Create a text file called NuGetPowerShellFix.txt, copy paste the above into it, rename to NuGetPowerShellFix.reg, then run.)
After merging the above file, restart Visual Studio.
If you're using NuGet in Visual Studio 2013 and get this annoying error, go to Tools | NuGet Package Manager | Package Manager Settings and click "Clear Package Cache." Restart Visual Studio. I know there are multiple solutions to this, so this is yet another to try.
I have had this problem intermittently as well. I just came across it again and ran across this thread. In my latest case, I realized I had VS 2013 open twice (which normally is not an issue, I do it all the time). Since the only common theme of others that seemed to fix it was circumstantially related to requiring administrator privileges I gave it a shot and closed both instances of VS and reopened my solution in a new instance. Ran the nuget install and it worked without a hitch.
Based on this, I am thinking that it is a file permission issue causing this spurious error. Sort of like when windows has a lock on a file in the bin directory after a debug session and will not let you compile the solution.
You may be able to resolve this by not running Visual Studio as Administrator.
Different cause, same error message; might be helpful for someone who runs into this one.
Since we needed to create a project on a share on a remote server in our network and ran into similar problems here's what worked:
map the share as a network drive, say R: (but I guess it would also work without this mapping)
open Internet options > Security > Local intranet > Sites > Advanced (via IE or control panel)
add either "R:" or "file://server.domain.xy" (the former will automatically turn into the latter once you reopen the dialog)
run the x86 PowerShell executable and do "Set-ExecutionPolicy RemoteSigned"
Once I did all that Visual Studio didn't complain that the project was in an untrusted location upon opening the solution again, and it successfully ran all the PowerShell scripts for the packages that get auto-installed when creating a new MVC application.
I'm having this issue now, i think what worked for me easy was that i just had to restart visual studio 2013 and run it as administrator...worked fast for me.
Yes, I know... I could set up a virtual machine running XP. Unfortunately our build environment is such that we need to be running VC2003, 2005 and 2008 concurrently and it would be much more convenient if I could run 2003 natively on Windows 7 for the few projects we have that require it.
I realize some things may not be available in the IDE, but I was able to run 2003 under windows Vista and if I could get the same base level of functionality under Windows 7 I would be extremely happy.
Right now I get an error opening the *.pdb file when I compile after switching vc2003 to run as Administrator under compatibility mode for XP SP 2.
Thanks!
Give XP Mode a try if you can't get it to run natively.
http://www.microsoft.com/windows/virtual-pc/download.aspx
I wrote a blog entry about this a while back that you can check out - http://technikhil.wordpress.com/2010/01/12/visual-studio-2003-and-windows-7-can-get-along-really/
The only thing I am stuck on right now is the global search functionality of VS 2003 - it hangs the application. My workaround is to use windows 7 search :-). Other than that - so far so good...
Update: I got the search to work as well by disabling the Aero functionality - I have updated my blog post with the details...
(Much of this repeats what's already been written above.)
I need to run VS2003 as adminstrator under Win7 64-bit, to support legacy projects (e.g. those that run on the original Xbox). The old XDK requires VS2003, so upgrading is not an option. I could run WinXP but I prefer Win7.
VS2003 is not officially supported under Win7 and trying to do so creates a couple of fairly annoying problems:
Find-in-files causes VS2003 to hang.
Linking fails due to a PDB file handle leak.
The Find-in-files hang is solved by using "Disable visual themes". Navigate to the VS2003 shortcut (Start-->Microsoft Visual Studio .NET 2003), right-click to get context menu, select Compatibility tab, Settings pane, and check "Disable visual themes".
The linker failure (LNK1201) happens when you run the program through the debugger, stop it, modify a file and build. The error is that a Visual Studio hold a handle to the PDB file, while the linker tries to write to that file. You can stop and restart VS2003 to bypass the issue. Works but is annoying.
You can also use the Microsoft SysInternals "handle.exe" utility to find, then close handles held by a process on a particular file. Write a script to call handle.exe and set up the VS2003 project to run that script as a Pre-Build Event. (See this thread.) But handle.exe requires running as admin.
You could hypothetically change handle.exe to run as admin using the usual steps (e.g. as a compatibility setting) but then handle.exe (apparently) runs in a nested shell, and then the stdout text does not get to the calling script.
You can make VS2003 run as admin, in which case the Pre-Build script also runs as admin, hence does handle.exe, and that works.
The remaining trick is to get VS2003 SLN files to open properly. If you simply make VS2003 run as admin automatically then the VS version selector fails to run VS2003. I don't know why, but it is the case.
You could associate SLN files to open using VS2003 devenv.exe instead of VSLauncher.exe. That works but then all new SLN files (2005, 2008, 2010, 2012, ...) fail to open.
So the final step then is to make VSLauncher.exe run as admin. This fails as of KB2492386 as this thread indicates. Uninstalling that update was the final step in this saga, to get everything to work.
PATCH NOW AVAILABLE
After some reverse-engineering, I found the incorrectly refcounted COM object responsible for the leak (it was off by 1) and developed a stable patch and corresponding article describing the fix. This addresses problems encountered while using Windows 7 thru Windows 10. Details and download available at:
http://bytepointer.com/articles/vs7.1_2003_on_win7_pdb_handle_leak_bug_unofficial_fix.htm
If you want to perform the patch manually, those details are also included.
NOTE: The SysInternals Handle tool workaround did not work for files on a network-share. The .PDB was not completely unlocked although the Handle tool claimed it was closed. My fix eliminates the problem once and for all and avoids any side effects.
Run this install. You need to run it from the setup directory, the setup.exe on the root of the cd will not work.
D:\setup\SetUp.exe /NO_BSLN_CHECK
Solution i found on the web which helped: For your visual studio, use application compatibility = windows vista SP2, and NOT WinXP SP3
I have a really dirty and pathetic workaround for the pdb problem.
Download and run Sysinternals-ProceXP, press CTRL-F enter the name of pdb(smt like ($ProjectName).pdb) that can't be created while linking. Double click when it is found.(if it can't be found run procexp with administrator priviliges)
Then you will see that the .pdb file is highlighted in the lower pane of the main screen. Right click it and select Close Handle. When you retry building your solution it wont raise an error.
I dont know if this solution can be scripted but it is at least better than restarting visual studio.
I've been using Visual studio 2003 on win7 since the very first RC edition was released :S
why do people have issues?
I have attempted to install VS2003 on Windows 7 64-bit using the Virtual Windows XP feature. I'm reasonably certain that this will be successful. The issue I ran into is that the installer wants IIS installed, and the XP installation provided by the Virtual XP doesn't have that enabled by default.
If you go to Add/Remove components, and try to add it, it will ask for the disc, which I didn't have on hand. Once I get my hands on the disc, I'm pretty sure that it will run fine.
If you haven't tried it for other apps, the Virtual XP feature is really neat...
I am experiencing the same issue; devenv.exe is leaving pdb files open after running the project. I have made a batch file to work around it, it closes all .pdb files open by devenv.exe:
handle.exe .pdb | awk "/devenv.exe/ { split($4, fd, \":\"); system(\"handle.exe -c \" fd[1] \" -y -p \" $3)}"
You will need to have handle.exe by sysinternals and awk by gnu in your path to make it work.
Use at your own risk. Closing handles can cause application or system instability.
In windows 7, there is the compatabiliy mode in the executable properties.
open:C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\
then right click on the devenv.exe and select properties. In the compatability tab, select the "Run in compatability mode" and select "Windows XP" in the dropdown.
Try that, I am not sure if it works, but it is worth a shot.
I am having no problems with Visual Studio 2003 on Windows 7 64-bit.
Navigate to VS2003 devenv.exe (probably C:\Program Files (x86)\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe)
Right-click and select Properties
In the Compatibility tab, check "Run this program in compatibility mode for:" and select "Windows XP (Service Pack 3)"
Check "Run this program as administrator"
I got Visual Studio .NET 2003 Working just fine on my HP EliteBook Workstation 8760W with an I7 processor and 12GB of RAM running Windows 7 Professional 64 bit by doing some advanced steps.
They go as follows:
Install FrontPage 2002 Server Extensions for IIS 7.0.
Install Visual Studio .Net 2003. Just skip when the installer command you to configure Frontpage 2002 Server Extensions.
Install .Net Framework 1.1 Service Pack 1 (download here).
Go to Control Panel > Administrative Tools > Internet Information Services (IIS) Manager. Highlight your machine, then double-click on ISAPI and CGI Restrictions. Change setting for ASP .NET v1.1.4322 to Allowed.
Then it will always show an alert with the following message
This program has compatibility issues...
just ignore that. Also, don't put it in compatibility mode in the properties of the IDE.
I did managed to install VS2003 on Windows 7 32 bit. However I had to do some IIS tricks in order to be able to run my ASP.NET project. When you install VS2003 Web Development component can't be selected. Basically you have to drop your VS2003 ASP.NET v1.1 into C:\inetpub\wwwroot\project_name and make it working on it's own as a standalone web portal first. Here is the steps I did.
Install IIS on Windows 7
Copy your VS2003 project to C:\inetpub\wwwroot\project_name. Right click on your project_name and Convert to application.
Following was my custom issue that didn't work until I enabled Windows Authentication even if I had no related settings in my web.config. Select your project_name > Authentication > enable both Anonymous and Windows Authentications.
Enable ASP.NET 1.1 in ISAPI and CGI Restrictions and make sure ASP.NET is added under ISAPI filters
Once I'm able to fire up my ASP.NET project in a browser go ahead and open project from your project location in my case is C:\inetpub\wwwroot\MHSScoreOrg\MHSScoreOrg.sln. I was able to run my project only when it was fully integrated on IIS.
I'm sorry, your build environment requires you to have VC 2003, 2005, AND 2008 running concurrently? I would really bet that your efforts would be better spent simply consolidating your build environment to just one environment.
Have you considered upgrading your solutions to vs2005, using MSBEE to target .net 1.1?