Re: Windows 10 2004 Vs 20h2
Cherrie Patete
I just bought a Xeon E5-1680v2 and I realized that it is not possible to overclock the CPU under Windows 20H2 with XTU anymore. You can set the Ratio Multiplier and also the additional Turbo Voltage with no problem, but the settings have no effect. What you are doing it is not possible to overclock the CPU. The max I can reach is 3391 MHz.
A short update. I have success to fix this problem.
I looked into my WSUS databse and saw that MS released last year a Intel Microcode update with Windows 2004 (KB4558130). This update is responsible that OC is no longer possible and shuts down the CPU to the base frequency. (Poor Intel and a poor solution to protect against Spectre). I can not agree that someone cuts my hardware into this way and I can not use my system as I expect and paid for.
Bingo. OC is possible again under 20H2. PerformanceTest works again using the full speed of the CPU again.
If someone is using Windows 10, 1809 in 64bit than please attach this file here, because this was the last version with OC possible (mcupdate_GenuineIntel.dll). If you want to test the solution (2004 Builds), go into the windows \system32 directory and rename the file. Before that you have to take the owner of the file or boot from a Windows PE version and rename the file.
I'm a bit slow.... can you show the navigation for how you got to that file, and what you renamed it to? You may have noticed that a good number here have said one cannot use XTU on W10 period. What version XTU are you using, also?
I for myself use the XTU version 7.1.0.4. and it works again. I do not know if this version runs stable with your OC settings. This must be tested by yourself or if you have to use a 6er Version of the software.
Any idea why my 1650v2 is stuck with default clocks even after proposed intervention?
I think I have somehow messed up the defaults. Even after uninstalling XTU, cleaning registry and reinstalling, it reads default multiplier as 39x (although it never sets it that high).
No. Have you renamed or overwritten the file? What XTU version and what Windows Build are you using?
What about your power plan. There are so many things in the system that can happen that I only can guess if the person is not sitting in front of it.
Hi Purecut, thanks for replying so fast.
To clarify, my system is a Z420 but I've been dealing with issue for quite some time now and I thought this could have been the solution. I renamed the file. Windows is 20H2 and XTU is latest (7.0.1.4). Are you on the latest BIOS for your system? I am guessing the BIOS patch for Spectre may also play a role?
It's so frustrating!
My 1650V2 used to hit 4.1GHz on all cores, and suddenly it reverted to defaults
I'm on the latest bios 3.96 and use also the bios settings from "Brian1965". When this behavior to your machine occurs during the work with 20H2 than it is definitely a windows update package on your system. Do you have the time to setup a blank 20H2 with a boot stick. You can also test this with a blank 20H2 on a boot stick. I take also for this the Ventoy version and the system is setup in 20 min. If you do this check the above file and than test.
This behaviour started well before 20H2 (I think it was 2001 or 2004). I tried both renaming the file (which didn't make a difference) and replacing it with previous versions. I tried two versions from stock Microsoft ISOs, 1709 and 1803. Each time, a startup repair loop was triggered and didn't resolve until I deleted the file from the console.
I didn't have time to do a clean 20H2 install on a seperate disk and test it there, unfortunately
so I found the time and changed my CPU to a 1680v2 and tested my work. What must I say the OC is working. What I must say I have not overwritten the file "mcupdate_GenuineIntel.dll". I renamed it (same as deleting for the system). Once again I'm using Windows 20H2 with the latest updates from the today MS Patchday.
I created an WPF application that I am attempting to install on different versions of windows and a variety of machines. On the machine that I have been building the application everything has been fine. I built the .appinstaller file using Pipelines and it installs on my Windows 10 Home - 21H1 build of windows. But I need it to work on my other machine which is a Windows 10 Pro - 20H2 machine. The issue...
When I install the application on 20H2 machine sometimes it will install and launch just fine but other times when I am attempting to update it or install it after I have uninstalled it, the app installer will launch and get stuck in a variety of spots. Sometimes it gets hung up on "Hang on while we get your app's information" and other times it will get to the install or update screen and you can press the update/install but but then it just sits there and says "Getting the system ready for install".
Taking a look at event viewer, sometimes the Microsoft.DesktopAppInstaller_1.16_12986.0. throws an error saying "Application Hang" with the hang type being Cross-process. I don't know if this is a specific issue to 20H2 version of windows or something different. I have looked in AppXDeploymentServer/Operational and there are a few errors related to the AppInstaller like....Appinstaller operation failed with error code 0x80D01001. Detail: Unknown Error.*Appinstaller operation failed with error code 0x80190192. Detail: Forbidden (403)
One of our developers got his development host machine updated to the 20H2 version of Windows 10, and after that happened the developer was no longer able to get step 4 above to work. Windows wasn't loading the Google USB driver when u-boot enumerated the USB gadget associated with Fastboot anymore. The obvious symptom was that Windows never "discovered" the new device when it was connected to the system.
It seems like that problem traces to the USB VID and PID that the u-boot USB gadget reports. We hadn't changed the default defconfig settings for "CONFIG_USB_GADGET_VENDOR_NUM" and "CONFIG_USB_GADGET_PRODUCT_NUM" from what they were in the distribution, and that seems to trace to a commit dating back to 2015. That commit sets the u-boot gadget VID to 0x0f25 which seems to be registered to "Netchip Technology, Inc", and PID to 0xA4A5 which would be a "Pocketbook Pro903" device.
I guess in retrospect the process outlined above did require us to manually install/update the Google USB driver the first time the Android device attached to a host. That manual installation of the driver associates the VID/PID u-boot enumerates with the Google USB driver. The problem seems to be that the new version of Windows 10 seems to no longer allow that kind of "Make this driver work with this device" kind of behavior to manually add VID/PIDs to the list that a device driver is known to support.
Our fix was to change the VID/PID to be something that is recognized by the Google USB driver. The reasoning was that once Android gets going, that USB port enumerates as a Google ADB device that is identified by Windows. So we should be OK to change u-boot so that when fastboot enumerates a device on that USB port it is the "bootloader" version of the same Google device.
The procedure described in the post mentioned below "MX8MM won't enter fastboot mode" was the way we got Fastboot to work originally, and it worked for months. Then the IT department pushed the Windows 10 20H2 update to some of our development computers. After that update on those computers, the solution described in that link doesn't work anymore. Also, we got a new guy who got a new computer with that version of Windows 10 installed on it and he couldn't follow the procedure either. So It seems like manually installing the driver doesn't work like it used to in earlier versions of Windows 10.
I'm guessing Microsoft decided that manually allowing a user to associate a driver with a device that the vendor didn't explicitly specify in the .inf file that's distributed with the driver was deemed a security issue.
I suppose one could try adding the VID/PID mentioned above to the .inf file that google distributes with the Google USB driver, to see if that allows the driver to work with a Netchips Technology Inc. (VID) Pocketbook Pro903 (PID) on Windows 10 20H2.
d3342ee215