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.
Related
Environment
I'm using Visual Studio 2019 version 16.7.2 on a Windows 10 VM, hosted by Parallels on a brand new MacBook Pro. The VM has eight virtual processors and sixteen gigs of RAM.
Nothing other than Visual Studio is installed on the VM.
What I'm trying to do
I'm trying to compile a Visual Studio solution consisting of seventeen projects. The projects are relatively small. They're all C# console applications or DLL libraries targeting .NET Core 3.1.
Problem
Typically a Rebuild Solution executed after a Clean Solution takes place in about ten seconds. A typical Build Solution (Ctl-Shft-B) that I execute throughout the day takes place almost instantaneously.
But occasionally, in maybe one build out of five, building the solution/projects causes VBCSCompiler.exe to consume 99% CPU usage and freeze up for approximately thirty to forty-five seconds prior to executing the build. Once it starts executing the build though, everything completes normally. This long delay which occurs time and time again is making my development cycle terribly frustrating. I'd like to find a way to eliminate this delay.
What's Changed
The build executed fine on my Amazon Web Server Windows 2016 m4.xlarge VM. I recently switched over to the Parallels VM to save money. That's when the problem began.
Again, I want to reiterate that the Parallels VM is clean. Nothing other than Visual Studio is installed there.
What I've Tried
The following tactics were applied to no avail.
(1) I turned off the Defender real-time virus checker.
(2) Based on the information in this post, I went to Tools | Options | Nuget Package Manager | General, and unchecked 'Allow Nuget to download missing packages' and 'Automatically check for missing packages'
(3) In Tools | Options | Projects and Solutions | Build and Run, I set the maximum number of parallel projects builds to one.
(4) Based on an answer to an unrelated question, I learned that I can view more information about the build process by setting 'MS Build project build output verbosity' to Detailed. I did so. I waited for the freeze to occur so I could examine the last line of output prior to the freeze. It reads as follows:
Using shared compilation with compiler from directory: C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Roslyn
This line always appears immediately before a freeze.
(5) Based on the output above, I Googled 'shared compilation' and discovered this post.
As a hobbyist programmer, the discussion that took place there, as well as the link in the accepted answer is well above my pay grade. It's unintelligible to me. If the answer lives in that post, I can't decipher it.
Any ideas on how to solve this intermittent freeze? If I can't figure it out, I'll have to assume it's something about my Parallels Windows 10 VM that's causing the problem, and revert back to developing on an Amazon server. I'd prefer to avoid that if possible because of the added expense.
Thanks for your consideration.
Best,
Festus
I'm working on a Raspberry Pi 3 with OS Raspbian Jessie. I'm using Eclipse CDT (for C/C++) and am trying to learn about OpenFrameWorks:
http://openframeworks.cc/
I installed everything according to the guides and imported everything to Eclipse. I thought it seemed to work out, but when I try to run some test-code I get the error "Unable to launch, binary not found." I look it up and find a potential solution, that I have to build the actual project first.
This is my problem, when I try to build the project Eclipse gets to about 20% and then the entire Raspberry freezes, forcing me to force a restart. How can I continue from here on out? I don't know if I still should try to build the project through Eclipse or if there is another way to actually run some test code for OpenFrameWorks.
I don't know if this is the best place to ask about this, but I'm thankful for all answers.
Eclipse is super slow on Raspberry Pi.
I recommend using the provided setup scripts to install dependencies. After you compile OF, use make files to compile projects.
In terms of editing code, I recommend using a light weight text editor (geany for example). I've tried CodeBlocks and Qt Creator, which are faster/less resource intensive than eclipse, but still pretty heavy for a system with limited resources.
Another option is to combine your computer the RPi:
Use projectGenerator to generate a project for both Raspberry Pi and your computer/IDE
Edit/test/iterate on your computer
When ready to run on RPi, sync the project using your preferred method(e.g. SSH/SFTP/git/etc.), then use make -j4(to use all 4 cores) in the RPi project folder.
The pro is you the quick compile/feedback times you're used to on your computer.
The con is this method won't work for RPi specific code (e.g. accessing GPIO, PiCamera, etc.)
Another option is to setup cross compilation, but getting everything ready is a bit laborious. (Although, once it's done, it saves time on the long run).
I have just released a new build of our Command Ops engine, which involved a conversion here from VS2010 to VS2013. I have included the retail vcredist_x86 package and it all seems to work fine for most of our users. However, I have two users running i3 systems - one Win7 Pro and the other Win7 Home Premium. They both report the same issue in that the game app won't launch - in terms that nothing is displayed on the screen. The game app is not listed in the App listing of Task Manager but there is an entry for it in the Processor listing. After 20 seconds another two entries appear in the Processor listing. One of these can be closed down but the other two refuse and can only be got rid of by rebooting. They can launch one of our visual basic apps that come with the install package but none of the visual c++ apps.
My gut feeling is that there is some difference with one or more of the redistributable dlls. Hence my question about whether there are any known differences based on an i3 system. Any advice would be welcome. Thanks.
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"
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.