I'm shocked that this hasn't been asked yet - but I can't install VS 2008 sp1 because my c: (%SYSTEMDRIVE%) has around 1.6 G free...
How in the world can I get sp1 to install?
Thanks
UPDATE:
I had the C++ bits installed - and I wasn't using them... Once I removed the C++ bits the installer stopped complaining.
ALSO - FYI - my %tmp% and %temp% already pointed to a different disk - but the installer isn't smart enough to figure that out i guess...
I've had similar problems with other installations. Re-setting TMP and/or TEMP to a partition with more space seems to have worked.
Per the system requirements from the release notes from Visual Studio 2008 SP1:
"3.8 GB available on the system drive, plus 600 MB on the drive on which Visual Studio is installed. Note: You can use the Disk Cleanup utility to remove temporary files." One option that could help you is to turn off system restore, restart, install, then turn system restore back on. Risky, but it may allow the install if you are absolutely desperate.
You're going to need more hard drive space. The VS installer will be doing a lot of downloading, uncompressing, and copying. So most of the 4gb is used for swap space, not necessarily for final installation.
It's also possible to turn of the swap space of Windows. Only do that when you've got plenty of RAM. Swap space can be found in My Computer/properties/Advanced/Performance/Advanced/Virtual Memory.
If you also wish to defrag at some point, do it when the disk is as empty as possible otherwise defrag (which can improve performance) will not work all that well, if at all.
Don't forget to activate swap space again afterwards.
sadly i had to remove c++ ( see my update in the question ) and that 'fixed' it...
Related
Im using widows 7 on my working PC and i know i should update (i have win10 on my common pc)
but i still need to finish some important art projects and updating my system now would cause me a lot of compatibility trouble with some wierd and old programs i use so im stuck with win7 until im done with theses projects.
However, last night i had an update (i thought there was no more updates wor win7 Oo')
and since then, my mouse software wont work anymore !
the software is called "Steelseries Engine"
i worked until late and the software was working, but today, it wont start.
i tried to restart, update, and reinstalling but the problem seems to come from some missing dll.
when i go into the install folder and launch it from there, it gives me the following error :
the program cant start because "api-ms-win-core-winrt-string-l1-1-0.dll" is missing.
Anyone could tell me how to repair that ? is it something related to visual c++ or something ?
I really need help, because i have to finish my project fast and witout my mouse setup/macros its going to take ages.
art
Thanks a lot.
I have got the same problem from yesterday, now.
Same message, same circonstances, "steel series" connected + windows 7, and i see no reason why it started. i reinstalled the steelseries engine exe i kept from my personal depository file, and it worked, then today i rebooted the PC and the dll message came back. Very strange. Stranger is that the steel series engine exe for the mouse and Co is not available for windows 7 anymore ont the steelseries website, it is written "For windows 8 and upper versions."
edit: i fixed the .ddl missing trouble, even though i don't know how it started. Thanks to CCLEANER, i found in the start list a long command line stating that the .dll will be deleted by a steel series operator. Delete this useless line (i don't know where it suddenly came from, may be a corrupted auto upgrade by SSeries) and reinstall steelseriesengine. I'm pretty sure this problem had nothing to do with W7. Enjoy.
My WiX bundle behaves very badly on a specific XP machine (x86). It stalls for six minutes during the "initializing" phase (before any bundled installers are run). From the logs it seems extremely likely it is due to the dodgy state of windows update on the machine:
[090C:0FC0][2018-03-27T19:31:17]i358: Pausing automatic updates.
[090C:0FC0][2018-03-27T19:37:23]w308: Automatic updates could not be paused due to error: 0x80080005. Continuing...
[090C:0FC0][2018-03-27T19:37:23]i360: Creating a system restore point.
I am using WiX v3.10 to make the bundle. I can find very similar situations from google search but the solution always revolves around updating the target machine. I need this installer to work as expected regardless. When I test a regular msi on the same machine it goes through fine.
Is there any way I can mitigate this issue? E.g. can I stop the WiX bundle from trying to pause windows update or something similar? The fact that the installer doesn't even notify what the issue is is extremely problematic, any user is likely to be confused.
The whole point of this WiX installer is to make an install package portable and simple but this actually seems LESS portable than just the msi...
Update: Also tried building the bundle with WiX 3.11 but got same problem. Though now it produces an actual error rather than installing regardless, which I suppose is an improvement.
UPDATE: after looking in the WiX source code it looks like WiX's Burn feature is making a few calls to Microsoft.Update.AutoUpdate (%SystemRoot%\System32\usoapi.dll - %SystemRoot%\SysWOW64\wuapi.dll) and a few other COM objects here and there.
See towards the bottom (screenshot) for a hot COM tip to quickly get an overview of different COM object models.
It must be this AutoUpdate call which hangs causing a timout along the lines of what is described in this blog. I believe you can find the exact source code location by searching for hr = WuaPauseAutomaticUpdates(); in the elevation.cpp WiX Burn source file (Github link). The actual calls to the COM object are in wuautil.cpp.
I am not familiar with the Windows Update Agent Object Model, but I suppose you could try to call the Pause function in a test VBScript just to see what kind of error you get on your problem system (if any). I can't see how you would get anything but a lockup on your problem system, so maybe try first on your main box? This is obviously at your own risk. I would assume a reboot or a call to Resume will continue the process as normal. I also see a call to SystemInformation.RebootRequired in the C++ code, which I have also added to the VBScript:
Set autoupdate = CreateObject("Microsoft.Update.AutoUpdate")
autoupdate.Pause()
MsgBox Err.Number & " " & Err.Description
Set sys = CreateObject("Microsoft.Update.SystemInfo")
MsgBox sys.RebootRequired
' autoupdate.Resume() ' Enable to resume AutoUpdate
Set sys = Nothing
Set autoupdate = Nothing
Let's face it: Windows Update is broken on your XP machine - isn't it? Maybe the WiX guys can add a shorter timeout? I am not sure what is better - 1) to shorten the timeout, 2) to remove the whole call or 3) to just bomb out telling the user that Windows Update is broken? Frankly the latter would probably alert the user to something very serious (often malware).
UPDATE: as you state yourself, Windows Update is almost certainly broken on this particular machine. I would try the MSI properties suggested below for testing, and then zap Windows Update as suggested here (same link as below) (techical).
But wait, maybe a malware check is in order, before wasting time on anything else?
Maybe try this free Sysinternals tool? Checks all running processes by hash using almost 70 scanning engines (no heuristics though). Fire up all you got (only running processes are checked)
Go File => Show Details for All Processes and then elevate to get to scan system processes as well. Now click "System" to scan drivers for example (*.sys files).
Often a great way to get your system admin to agree to rebuild a problematic machine for everyone. Suddenly you go from "deployment problem" to "machine specific problem" - and it is out of your hair. GIGO problem.
Nicely formatted and phrased question BTW. And just for reference: Sysinternals.
Workaround?
I have never seen this, but I have seen some MSI files suddenly pausing for a long time whilst installing whereas they would install quickly during test installs just minutes before.
My guess is that this could be related to system restore and the creation of a restore point at certain "intervals". I am not sure what algorithm is used to determine when such a restore point is created and not, but I wrote an answer many years ago on the issue of speeding up MSI installations: How can I speed up MSI package install and uninstall?
As you will see, you can disable the creation of a restore point for your setup by setting an appropriate command line involving the property MSIFASTINSTALL (and a few other tweaks - please just read the linked serverfault.com answer). I would try this to see if your setup stops locking up / hanging.
Causes?
Some hits from the web:
Could it be that Windows Updates is also trying to create a restore point at the same time as your MSI-package? Setup hang when trying to disable windows updates (PhilDW)
Could it be that the Windows Update feature is corrupted?
Similar issue: WiX Toolset installs VC++ redistributable (x86) 2015 too slowly
I would first try the MSI properties mentioned as a "workaround" above, and if that doesn't work, I would try to see if fixing Windows Update as explained in the link directly above works. Crucially I would also let Windows Update complete its task of installing all available updates before running your bundle again.
Hot Tip (COM)
I don't like to recommend commercial tools, but we all need some quick tricks and quick wins at times - which is what this is about. Get hold of VbsEdit and use its light weight object browser to quickly see details from any COM object model. Just do a CreateObject and you will instantly see the object model in the object browser to the right in the application window (View => Object Browser if it is not there).
Just type in something like this:
Set installer = CreateObject("WindowsInstaller.Installer")
I find this to be a time-saver when I need to deal with legacy COM stuff and Visual Studio is very sluggish. I just have the VbsEdit trial version, and it allows basic editing. And let's throw in a rant: why on earth do they not make a Javascript version? I am missing something - as usual :-).
Throwing in a second screen shot to show a more interesting object model information tidbit:
Should you want to try it, here are some other CreateObject statements you can try:
Set autoupdate = CreateObject("Microsoft.Update.AutoUpdate")
Set fso = CreateObject("Scripting.FileSystemObject")
Set scriptshell = CreateObject ("WScript.Shell")
Set dictionary = CreateObject("Scripting.Dictionary")
Set shell = CreateObject("Shell.Application")
A very strange, presumably meant to be helpfull behaviour of Visual Studio 2012.
When I enter a double in vb.net like:
Dim myD as Double = 1.4
When I hit enter of move my focus another way, the formatting kicks in and changes the above to:
Dim myD as Double = 1.39999999999999998
or 1.6 as
Dim myD as Double = 1.6000000000000001
This behaviour does not appear to happen for all doubles. 1.3, 1.5, 1.7 and 1.8
See this youtube movie for the behaviour in action:
http://youtu.be/afw4jg58-aU
Why, and more important, how can I prevent this?
Edit:
Extensions installed are:
Second Edit
The behaviour seems to have gone away. I do not know what has caused this so for future reference this is useless to anyone, but for now, I'm happy that I don't have to go troubleshooting as suggested.
The exact same issue is also reported in this question. Which applied to VS2010, otherwise without a usable answer.
This is an environmental problem, code is getting loaded into Visual Studio that messes with the FPU control word on your machine. It is a processor register that determines how floating point operations work, it looks like this:
The Rounding Control bits are a good source of trouble like this, they determine how the internal 80-bits precision floating point value is truncated to 64-bits. Options are round-up, round-down and round-to-nearest. The Precision Control bits are also a good candidate, options are full 64-bit precision, 53 and 24 bits.
Both VS2012 and the .NET Framework rely on the operating system default, with the expectation that this will not change afterwards. Pretty hard to diagnose trouble arises when code actually does change it, your observation strongly fits the pattern. The most common troublemakers are:
code that uses DirectX without the D3DCREATE_FPU_PRESERVE option. DirectX reprograms the precision and rounding control bits to squeeze out a bit more perf.
code that was written in an older Borland language product. Its runtime library initializes the FPU control word in a non-standard way. Otherwise a generic problem with software that relies on old runtime library or an old legacy initialization that was carried through in later releases.
in general, any code that uses a media codec or media api. Such code tends to reprogram the FPU to squeeze out perf for the same reasons that DirectX does. Especially notorious in a product I worked on which uses such codecs heavily. The codebase was peppered with calls that reset the FPU control word after making a call into external code.
Finding and eliminating such code can be very difficult. DLLs get injected into another process by a large variety of well-intended malware. The SysInternals' Autoruns utility can be very useful, it shows all the possible ways code can be injected with an easy way to disable it. Be prepared to be shocked at what you see and readily disable stuff that doesn't carry a Microsoft copyright.
For dynamic injection, you'll need a debugger to see what is loaded into VS. Start VS again and use Tools + Attach to Process to attach to the first one, selecting the unmanaged debugger. Debug + Windows + Modules shows you what DLLs are loaded. Do beware that the DLL can be transient, a shell dialog like File + Open + File will dynamically load shell extensions into VS and unload them again afterwards. Good luck with it, you'll need it and sometimes the only fix is a rather drastic one.
I had the exact same issue with Visual Studio 2012.
The "solution" if it happens to you is:
write your number in your code
let VS screw it up, e.g. when you move to another line
CTRL-Z to revert VS mess
continue writing your code
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'm having an issue which I'd have thought others might have come accross, but I can't find any posts.
My (small) WiX projects are taking ages (2-4mins each) to build on our build server, but are much quicker on my desktop (a few seconds).
After some poking around I've narrowed it down to McAfee scanning the temporary files created by light (located in the TEMP user environment variable). I don't know why it's taking so long to scan - disabling the AV has got the build time to well under 2 mins, previously it was over 20!
Now my issue is how to exclude these temp files from the AV. I don't want to exclude the TEMP folder for obvious reasons and there doesn't appear to be a way of excluding by file name without creating a big hole in the AV.
So I guess my question is, is there a way of configuring light.exe to use a different path other than TEMP? I tried some command line switches with no luck. Maybe I could add something to the Light.exe.config?
Cheers.
Can you not just disable real time antivirus scanning on your build machines? My argument for doing this would be that your VM should be full scanned and then disabled and that all files making it's way into the build machine are coming from source control and / or file shares that should have already been scanned at various points upstream in the process.
We ran over 100,000 builds a year at my last job and A/V would have killed us.
Otherwise, if you type light.exe -? you'll see there is an environment variable called WIX_TEMP that overrides the temp directory.