Jump to content

Windows 10 GWX Update Removal Tool for Windows 7 and Windows 8.1


rn10950

Recommended Posts

Introducing...

rn10950's I Don't Want Windows 10

 

g4JOxfr.png

 

After I saw the GWX update showing up on my PCs, I immediately opened up Visual Studio and got to work on this. While any of us can just open up Control Panel (while it lasts) and uninstall the update, how many regular users can? So I created a GUI shell for the WUSA command to make it easy for anyone to uninstall this piece of adware.

 

Download for x86/x64 Windows 7 and Windows 8.1

Source Code

 

If anyone has any issues, let me know. I will try to fix it as soon as possible.

 

 

EDIT: Version 2.0 is here!

 

Here are the changes in this release:

  • Improves compatibility with Windows 8.1
  • The x86 build works on both 32-bit and 64-bit Windows
  • MFC and VC++ classes are embedded in the application

EDIT 2: Version 3.0 is here!

 

Here are the changes in this release:

  • Fixes the MessageBox problem
  • Kills GWX.EXE after update removal
  • Has command-line support
  • Major code re-writes

Special thanks to Glenn9999, NoelC, dencorso, and jaclaz for helping me with these updates.

Edited by rn10950
Link to comment
Share on other sites


Ok as I mentioned before, I could comment on the program, but would be off-topic to the other thread.  Now that this thread exists:

This happens on your 32-bit version.

// for some retarded reason, %windir%\sysnative\wusa.exe does not exist// so we must tell x64 users to run the x64 executable until we can figure// out how to use the native system wusa from a 32-bit application

As for this, look up DisableWow64Redirection and RevertWow64Redirection.  (Edit: I got reminded by reading rn10950's new code that these are wrong.  These are the aliases I used.  The real functions of concern are Wow64DisableWow64FsRedirection and Wow64RevertWow64FsRedirection.  While the OP figured out the right functions, I thought I'd add this for anyone who might search looking for this answer here) You will need to call those as you did IsWow64Process and need to use them anytime you have a 32-bit process that needs to address configuration assets of a 64-bit system to work properly.  Be sure to call the Revert function very soon after you have to Disable.

you must be an Administrator

You can force that through your application manifest to elevate itself to Administrator privileges (with the accompanying "do you wish this program to change things?" dialog box).

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">  <security>    <requestedPrivileges>      <requestedExecutionLevel level="requireAdministrator" uiAccess="false"/>      </requestedPrivileges>  </security></trustInfo>

Interesting idea, though.  I don't know how much demand you're getting, but it'd be half-interesting to make this app more generic if there is some interest.

Edited by Glenn9999
Link to comment
Share on other sites

Resolved the first error myself (deinstalled/reinstalled all VC++ runtimes).  Went ahead and ran your app and received "This application needs Windows 7 or Windows 8.1" unconditionally.
 

bIsSupported =  ( (osvi.dwMajorVersion == 6) && (osvi.dwMinorVersion == 1) || ( (osvi.dwMajorVersion == 6) && (osvi.dwMinorVersion == 3) ));

Minor version may be 2 as well in order for your app to be valid.

 

Link to comment
Share on other sites

The VC++ error workaround is included in the readme files in the zip file with the binaries in it, as well as the runtime installers. The GWX update, as far as I know, doesn't affect Windows 8.0, only 8.1, which is NT 6.3 not NT 6.2. If you have the GWX installer in Windows 8.0, please let me know.

 

Mine (Win 8.1 fully patched) returns 2 as a minor version (I know, I checked it myself).

 

As for your MessageBox problem, it happening seems to indicate that some of your app messages aren't being processed.  Most Google responses point to WM_PAINT as the culprit, but I don't see a main message pump loop and don't have VC++ to play with here, so hopefully that gives a direction to look.

Edited by Glenn9999
Link to comment
Share on other sites

And....here's the explanation.

 

 

In Windows 8.1, the GetVersion(Ex) APIs have been deprecated. That means that while you can still call the APIs, if your app does not specifically target Windows 8.1, you will get Windows 8 versioning (6.2.0.0).

 

 

It's something I've already done in the past for a while (using compatibility manifest entries), but it looks like you need the app compatibility section of the manifest now in order to be fully Win 8.1 supporting.

 <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">    <application>      <!--The ID below indicates application support for Windows Vista -->      <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>      <!--The ID below indicates application support for Windows 7 -->      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>      <!--The ID below indicates application support for Windows 8 -->      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>       <!--The ID below indicates application support for Windows 8.1 -->      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>       <!--The ID below indicates application support for Windows 10 -->       <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>    </application>  </compatibility>

My app check with that manifest in force produces a minor version of 3.

 

Fun stuff... :S

 

Edit: And here's what GetVersionEx is deprecated in favor of.  Looks pretty easy to implement.  Edit again: I updated the manifest above for Windows 10 compatibility.

Edited by Glenn9999
Link to comment
Share on other sites

What do you mean by "similarly broken"?

 

It returns the system version of whatever the latest version your application is manifested for.  The change is by design (however twisted the thinking).  You're no longer supposed to care what version of Windows you're running on.  Windows is in control, not you.  Didn't you get the memo?

 

You'd think you could craft an iterative function based on IsWindowsVersionOrGreater and I've tried it.  At the moment it reports version 6.3 service pack 0 on Windows 10 build 10130 with an application built in Visual Studio 2013 and manifested for Windows 8.1.

 

That reminds me to try a VS2015 build.

 

Edit:  Tried it.  The iterative IsWindowsVersionOrGreater routine just appears to return the highest version number the application is manifested for.

 

-Noel

 

 

P.S., See:  http://arstechnica.com/information-technology/2014/11/why-windows-10-isnt-version-6-any-more-and-why-it-will-probably-work/

Edited by NoelC
Link to comment
Share on other sites

What do you mean by "similarly broken"?

 

It returns the system version of whatever the latest version your application is manifested for.  The change is by design (however twisted the thinking).  You're no longer supposed to care what version of Windows you're running on.  Windows is in control, not you.  Didn't you get the memo?

 

I meant in terms of what it returns.  On my system, GetVersionEx returns 6.2 in a program with no manifest, which is false since it's a Windows 8.1 install.   This also happens to describe rn10950's program(s) as a OS version check exists using this function, so they are effectively broken.

 

But you basically explained why.  In the future, versioning is basically meaningless, so you have to resort to other methods.  In that sense, the application manifest is what determines the version returned, and what is put there determines what kind of app compatibility measures the OS undertakes.  So the application manifest (as I quoted it) becomes paramount much more than the OS version.

 

Hence, rn10950's primary corrective is to add that compatibility manifest as I quoted.  Though it might be much more preferable from an OS standpoint for him/her to use IsWindowsVersionOrGreater than use GetVersionEx as was done.

 

Of course, the problem with the application manifest is that I forsee having to do a release of my programs (BatchPatcher, namely, as it's the only thing I've done where OS ver return is important) every time Microsoft releases an OS.

Edited by Glenn9999
Link to comment
Share on other sites

I'd like to be able to read the real version number for logging purposes (e.g., someone sends in a log from software where they've seen a failure, and we can tell what OS they were running it on - that kind of things).

 

I believe I'll be adding something that reads the registry to do this.

 

-Noel

Link to comment
Share on other sites

I would have used IsWindowsVersionOrGreater but the issue is that the update is only present on Windows 7 or Windows 8.1, not Windows 8 RTM. Like NoelC said, versioning is going away, but there is still limited use cases where it is required, like this. I still don't know what MS was thinking when they made Windows 8.1 NT 6.3 while still reporting NT 6.2 to applications.

Link to comment
Share on other sites

Reading the file versions of NTOSKRNL.EXE, NTDLL.DLL and SMSS.EXE should be the most reliable way for determining the true windows version, and ought to be reliable, isn't it so?

Link to comment
Share on other sites

Like NoelC said, versioning is going away, but there is still limited use cases where it is required, like this. I still don't know what MS was thinking when they made Windows 8.1 NT 6.3 while still reporting NT 6.2 to applications.

FWIW, it looks like the versioning will still happen with applications, but through that manifest and not entirely through code.

 

Edit: Tried it. The iterative IsWindowsVersionOrGreater routine just appears to return the highest version number the application is manifested for.

-Noel

 

 

Actually, it's returning 6.3 on mine, as opposed to 6.2 on GetVersionEx.

Link to comment
Share on other sites

Actually, it's returning 6.3 on mine, as opposed to 6.2 on GetVersionEx.

 

I imagine they'll bump that up to 10.0 when Win 10 goes to RTM, but only for applications with a Win 10 manifest.  And I wouldn't put it past them to change the GUID for the "Compatible with Win 10" line in the manifests either.

 

The point being the version into APIs aren't what you need if you want to know the real version.

 

Dencorso, you're probably right - especially since it looks like there will never again be a way to hide updates that deliver new versions of those components.

 

-Noel

Link to comment
Share on other sites

Reading the file versions of NTOSKRNL.EXE, NTDLL.DLL and SMSS.EXE should be the most reliable way for determining the true windows version, and ought to be reliable, isn't it so?

 

The point being the version into APIs aren't what you need if you want to know the real version.

 

Dencorso, you're probably right - especially since it looks like there will never again be a way to hide updates that deliver new versions of those components.

 

Obviously it'll have to do some heuristics when unexpected versions are found, but it should be reliable enough.

Incidentally, a similar method, but based solely (AFAIK) on the version of kernel32.dll, has been the way Kan Yabumoto settled on for xxcopy to know which windows it's running on, for quite a long time already... The loss of a sane versioning mechanism is another great accomplishment of the more recent versions of windows, so MS must be quite proud of it! :crazy:




			
		
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...