Long story short, this is what I get when I try to install Qt 5.4:
My system is Windows 8.1 x64 and I have plenty of space on all of my drives. What I've tried so far:
using both offline and online installers
resetting %TMP%/%TEMP% environment variables (I use tmpfs partition for that)
running installer as administrator
Based on the comment discussion, it seems to mean some corruption on your system that may trigger this failure as a reinstall of your Winows 8.1 seems to have made this working.
For future reference: in general, you could debug this issue by trying to install 32 bit verison instead of 64 bit. If that does not work, you could pick up minimal installation. If that does not work, you could try another compiler variant, etc.
Naturally, you always need to make sure that you run this as system administrator, too.
Disclaimer: this fresh issue reported could also be an issue under "extreme" circumstances:
Segfault when running installscript.qs using "replace"
Related
I'm working with source code of Unreal Engine 4.27.2. A lot of time I built an engine at my old Windows 11(I don't remeber a version), that I set up with a lot of any Tweaks. Everything was good: I had a full CPU load(100%, 180Watt) while building a project and got a built project for 30-40min.
But for some reason, I reinstall my windows to more new ones. It was Windows 11 too. And from this moment I have trouble with the building of the Engine. It can load my CPU for 100%. I have reinstalled about 10 different Windows 10\11, different versions, different variations of all. I tried to use a lot of usually-for-me Tweaks, settings, etc. But nothing can't load the CPU for 100% while building.
What I tried to do:
Setup a Power Options to Ultra\Maximum
Disable the default windows defender
Disable default any spy utils using regedit and policies-editor
Set high priority for cl.exe\MSBuild.exe\link.exe using Regedit(didn't work out, didn't set)
Make 4th point using .bat commands with infinity loop(where I set high priority for cl\MSBuild\link). It became a bit better.
Tried to make env-var CL with value /MP
Tried to kill any other processes
Tried to set the highest performance for my CPU using tools of my ASUS Motherboard.
I'm sure that I did many other things, but I don't remember.
Now I use Windows 10 LTSC 21H2 19044.1381(installed 6 hours ago) and the project building for 5 hours and 20%\50Watt loading of CPU!!!
I tried to resolve it for more than one week! Help, please :(
I will be very grateful for any help!
PS: my PC:
i7 12700k
64Gb RAM(DDR4)
Samsung 980Pro and 970 Evo Plus(tried to build on both of them)
Also I use MSVC 19
I found an issue.
The problem was bound to my OS settings. For some reason, all apps had 'below normal' priority in the Task Manager, so my compiler didn't want to load my CPU over ~20%.
I resolved that using Bill2's Process Manager and set minimum priority for all processes 'normal'. Instead of 5 hours of build, I got 25min.
I am new to valgrind, using a windows system. But this pop up when I try to use it. What can I do?
Valgrind is not available for Windows. On their home page, it says:
It runs on the following platforms: X86/Linux, AMD64/Linux, ARM/Linux, ARM64/Linux, PPC32/Linux, PPC64/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux, MIPS64/Linux, X86/Solaris, AMD64/Solaris, ARM/Android (2.3.x and later), ARM64/Android, X86/Android (4.0 and later), MIPS32/Android, X86/Darwin and AMD64/Darwin (Mac OS X 10.12).
For alternatives, you can refer to this stackoverflow question. Many people have listed other options.
EDIT:
Since you are using WSL, that does change things. (Next time, it would be good to add that sort of information to your question. Even if Valgrind worked on Windows, using WSL does change the answer.) You should know that valgrind will only work for Linux binaries then. You won't be able to use Visual Studio code.
Otherwise, it should technically be possible, but I've worked with WSL and since it's still in its early stages, things don't always work as you expect. It might just be in your case though, that you need to do the first possible fix by sudo apt install libc6-dbg.
If that doesn't work, here is an answer about how to install it. No guarantees that this works though for you.
TL;DR What is the sane way to automate invokation of VS 2017 vc_redist when called in a chain of several installers?
The Visual C++ Redistributable Installer that MS provides for VS 15.x (VS 2017), namely both (14.15.26706 - VS 15.8.4)):
vc_redist.x86.exe
vc_redist.x64.exe
As part of our full product installation, I have to run several vcredist installers (also older versions) silently.
The problem now is that these installers will refuse to install if a reboot is pending (e.g. "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" - PendingFileRenameOperations).
When calling these installers with vc_redist /q, they will even trigger an immediate system reboot. This can be fixed by calling them with /q /norestart, however:
When calling vc_redist /q /norestart, and if a reboot is pending prior to this installer, it will return MSI exit code 3010 which indicates that a reboot is required.
However, AFAIK, this exit code also indicates, that this very setup requires a reboot to complete.
Actual question
So, I cannot distinguish whether this installer was succesful and just requires a reboot at the very end of my installation sequence (I do install otehr stuff before and after) - or whether the installer actually refused to do anything and I would need to restart the system and start this installer again!
How can I call this vc_redist in a chain of different third party installers and
ideally require just one reboot at the very end
at the very least, determine whether it installed successfully.
Some additional infos, fwiw:
Not sure these helkp with the question, but for completeness sake.
The installer GUI clearly indicates what is going on: (sorry, german Windows)
"No action was taken because a reboot of the system is required."
This is an InnoSetup built installer for our "product suite", that will be used by customers, the installation order goes as follows:
Run MSVC 2005 (VC8) 32 bit vcredist
Run MSVC 2010 (VC10) 32 bit vcredist
Run MSVC 2017 (VC141) 64 bit vcredist
Run MSVC 2017 (VC141) 32 bit vcredist
Run a few other third party dependecy / library installers
Install the actual application files (via InnoSetup)
Reboot (ask) if any installer indicated a required reboot.
As you can see from this sequence, rebooting after each vcredist woud be insane, and luckily it seems only the 2017 redist exhibits this unfortunate behaviour so far.
Of note: My trial runs on my dev machine all started with a reboot already pending at "step 0", and both the VC2005 and VC2010 installer run just fine (as verified through their GUI progress) even if a reboot is pending before hand. It's the VC2017 installers that refuse to do anything if a reboot is pending.
MSU Packages: After decompiling the vc_redist.x64.exe - which is a WiX bundle - using this command:
dark.exe -x Extract vc_redist.x64.exe
I found that the bundle installs: Update for Universal C Runtime in Windows - KB2999226. This component consists of Windows Update files (*.msu - used by Windows Update) and not just MSI files. I would suspect that they could be designed to require a reboot before allowing installation, but I don't have proof.
Suggestion: Run a check to make sure KB2999226 is installed. How to do this? I don't know a Win32 call, but the WiX guys will probably know. Here are some other suggestions.
Windows: How to List All of the Windows and Software Updates Applied to a Computer
Why are “get-hotfix” and “wmic qfe list” in Powershell missing installed updates?
Identifying installed updates on Microsoft products
The actual Windows Update Files are (over time these file names could change as new versions of this installer with the versionless file name - vc_redist.x64.exe - are released):
Windows6.0-KB2999226-x64.msu
Windows6.1-KB2999226-x64.msu
Windows8.1-KB2999226-x64.msu
Windows8-RT-KB2999226-x64.msu
In other words for Vista, Windows 7, Windows 8 et al. Various Server OS's as well. Windows 10 has this component built-in.
Corporate Deployment: In a corporate environment I would deploy these *.msu files via
the distribution mechanism available - whatever it might be - for
example SCCM - before installing the vc_redist.x64.exe package.
This should yield better control of the distribution process as you get error messages straight from the MSUs themselves.
Frankly these are core-SOE components in my opinion. I don't know why Microsoft keep these runtimes out of the main OS installation. They are crucial for most software.
A description of the decompilation approach using the WiX toolkit's dark.exe binary can be found here: How can I compare the content of two (or more) MSI files?
Strictly speaking, error 3010 is a success result. It means that the install has completed but requires a reboot. I'm not aware of anything to indicate that it means the install didn't start at all. The typical "won't install if reboot pending" is a result of using a launch condition based on the MsiSystemRebootPending property. Failures due to this launch condition do not return return a 3010 result - they usually return a 1602 error as a kind of "user cancel" error.
I am currently running Enthought Canopy version 1.5.2 full version, through an academic license at a 64bit Windows 7. I was a happy user for a couple months until a 'pythonw.exe has stopped working' issue rendered the software useless. This issue shows up when I open the editor (Ipython+Canopy's GUI) and does not allows me to use the software at all. I have tried the following solutions without luck:
Fresh install deleting several folders manually (https://support.enthought.com/hc/en-us/articles/204469700-Uninstalling-and-resetting-Canopy)
Fresh install+clearing python registry keys under hkeys_user and hkey_system and pythonw.exe related keys into windows regedit.exe (Problems in fully uninstalling Python 2.7 from Windows 7)
My second try actually gave me a false sense of victory, when Canopy worked for a couple hours, until the same issue happened taking all hope with it.
I don't know what to do anymore, any help would be much appreciated.
I had this problem also. And discovered it was due to my windows firewall blocking pythonw.exe
Either turn off the firewall. Or create exceptions for pythonw.exe (but be warned this files occurs in a few different directories. And I'm not sure which one gave the specific issue.
In the end I installed a new firewall (COMODO). And now everything works...
I've written a C++ console application in Visual Studio 2019 and am trying to deploy it to another windows laptop. Both laptops are up-to-date with 64 bit Windows 10, and my target laptop has installed/up-to-date .NET Framework, vc_redist.x64.exe, and DirectX.
In terms of deployment method, I followed this Microsoft walkthrough word for word, with the added step of ensuring that my newly created "setup" project was also targeting x64 platform, since some of the external libraries in my code required x64. The resulting "setup" .exe/.msi pair work as planned on the source laptop - installs and runs with no frills required.
Installation goes fine on the target laptop, but launching the program gives the error mentioned in the title of this post. After a few hours of trying to figure it out, I think I have an idea where the problem is coming from, but first, I'll share what I've tried, which is basically every recommendation found by googling this error code:
clean boot
SFC scan
chkdsk c: /f /r
repairing/fresh installing all of the frameworks mentioned in the first paragraph
running both the application installer and the installed application as administrator
restarting laptop and reinstalling application after all of those changes
What I think is the root of the problem:
In the setup/deployment project in VS, three of the "detected dependencies" (MSVCP140D.dll, ucrtbased.dll, VCRUNTIME140D.dll) have filepaths through …\System32\ rather than the identical dependencies that could be found in …\SysWOW64. The other two detected dependencies are external 64-bit DLLs (which is why I specified my entire project to x64). When I run my application through Dependency Walker, it agrees that the three formerly mentioned dependencies are "wrong CPU type", while the two latter ones are fine. This scenario does not, however, explain to me why install/run (outside of VS) works fine on the source laptop (shouldn't it not work if VS is packaging a mix of 32 and 64 bit dependencies?). In fact, running the application through Dependency Walker on the source laptop reveals the exact same thing as on the target laptop - the same 3 dependencies are "wrong CPU type", yet the application runs here.
I do not see an option in VS to change the "setup" project to read the 64 bit filepath. I have tried manually swapping in the 64-bit DLLs at various stages (including restarting the computer between DLL swap and application run), which did not seem to have any effect. In fact, I tried replacing the 3 relevant DLLs in the System32 folder with the DLLs from the SysWOW64 folder (my idea of a cheap workaround for not being able to change the filepath - just change the file) and this just caused me to get the same error on my source laptop as I had been getting on my target laptop.
All of this stuff is relatively new to me, so please let me know if I'm foolishly overlooking some fundamental detail with my process/project - at this point it would be nice if that were the case and this is easy to fix.
Wrote this before I noticed the above comment had already answered.
Just leaving it in.
Debug Binary: Looks like you have deployed a debug version of your binary (The D in the file name: MSVCP140D.dll). Try to compile in Release mode and deploy the new binary.
Cause: Debug binaries generally need the debug-versions of the VCRedist binaries to exist on the box you try to run the binary - they are only available on developer PCs with the SDK (and / or Visual Studio) installed. That error message: 0xc000007b means "STATUS_INVALID_IMAGE_FORMAT".
Tips: There are some resource links here and some tips on how to debug deployment problems.