Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


Sign in to follow this  
RyanVM

Making Windows think KB836528 has been run

Recommended Posts

OK, I'm getting really frustrated by this. On all my fresh installs now, Windows Update is prompting me to run the Doomjuice, Mydoom, Zindos removal tool (KB836528). So far, my quest to find a registry key which makes Windows think it was run (similar to the GDI+ Detection Tool) has turned up nothing. The best lead I've had is that the tool makes a RemovalTools registry key and adds an entry for that tool with a value of OK when it's run. However, I've tried manually adding that entry on a fresh install and Windows Update still thinks the tool must be run.

Has anybody figured out a way to trick WindowsUpdate???

Share this post


Link to post
Share on other sites

Have you tried integrating it into your source? That worked with the GDI detection tool for me, I didn't use a registry hack.

Share this post


Link to post
Share on other sites

I'm not sure I understand exactly what you're asking.

Share this post


Link to post
Share on other sites

Well, I figured out a way that works. As some of you are aware of, blastcln.exe is already on the XP CD. Also, you can see on a fresh install that at some point during XP setup, blastcln.exe is run. The evidence for that is a log file in c:\windows\debug named blastcln.log. I also noticed when running doomcln.exe that a doomcln.log was also created in the same directory. This got the gears spinning in my head. So I tried renaming doomcln.exe to blastcln.exe and compressed it and put it in i386. And (not) to my surprise, it worked! doomcln.log was present and WindowsUpdate no longer wants to install. So for the next release, that's what I'll be doing unless someone can find a better solution.

Share this post


Link to post
Share on other sites

that's the closest thing i've seen to totally removing this dreaded tool :)

i simply hid it away in WU ...

ur steps fools WU to think it's been executed or installed ...

what if you dump the doomcln.log file? does WU look for the exe or log (string search)??

Share this post


Link to post
Share on other sites

I tried nearly every combination of file/registry settings I could think of, but to no avail. And I'm really not tricking WU into thinking it was run, since it was actually run ;). I'm just fooling Windows setup into running something other than what it thinks it is.

Share this post


Link to post
Share on other sites

Last night I integrated all new 5 fixes with /integrate.I tested this new one on virtual pc and it said no critical updates.Before integration I had that stupid Mydoom false alarm.Really dont know the reason :)

Share this post


Link to post
Share on other sites

Yeah, it's driving me nuts. Oh well, if the workaround works, the renamed blastcln.exe is 40KB extra on the download size - not exactly a big deal for an 11.5MB file. And it adds an extra 7k to the overall size of the CD :P

Share this post


Link to post
Share on other sites

hi ryan. would like to confirm this... to remove the latest KB836528 patch from WU, ill just have to do this...

- download the KB836528 update (for english language)

- decompress the DoomCln-KB836528-v4-ENU.exe file. (english file)

- on the decompressed folder, rename the uncompressed doomcln.exe to blastcln.exe

- compress the blastcln.exe file to blastcln.ex_ to the source i386 folder.

Share this post


Link to post
Share on other sites

Yes, that should work. But there's another way which supposedly works that I'm in the process of verifying.

Share this post


Link to post
Share on other sites

oh... hmm, i did the same... however, an error appeared during the registering component stage... kinda forgot what the exact message was but it was a fatal error or something... checking at the log file (%windir%\debug\doomcln.log), i found the following message...

Microsoft MyDoom removal tool (build 1.227) started on Sun Dec 19 12:52:12 2004
Checking 23 processes.
Checking startup registry keys for current user.
Checking keys for 1 other users
Insufficient memory - 0 bytes needed
Can't query value for `Startup`, datasize=148, err=00000002
Deleted registry key 80000002:Software\Microsoft\Windows\CurrentVersion\Shell
Checking known MyDoom filenames.
Microsoft MyDoom removal tool stopped on Sun Dec 19 12:52:12 2004

wonder if i did something different.

i just repacked the doomcln.exe file with the makecab...

Share this post


Link to post
Share on other sites

this is wierd...

i tried decompressing the blastcln.ex_ file i just integrated onto the source with the one i re-downloaded from the web... thinking there was just an integrity problem with the files that were burned... i found no differences using the FC /B command.

however, when i tried re-compressing the downloaded file to a cab via makecab and did a file comparison... i saw some differences... grrr... im confused now...

00000036: 02 93
00000038: 5C 2A
00000039: 73 61

Share this post


Link to post
Share on other sites

tried looking for "doom" words in the registry... so far, i have found a couple of appearances, but this one seems to be relevant.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RemovalTools]
"MydoomTool"="OK"

i wonder if this in combination of adding a dummy log file (%windir%\doomcln.log) on the debug folder is enough to trick WU into thinking the doomcln.exe has been executed.

sorry for the succeeding questions...

i just happened to look at the %windir%\setuperr.log file... and i saw these... (snippets only)

Error:
Setup had problems registering the following OLE control DLL:

C:\WINDOWS\system32\blastcln.exe

Contact your system administrator, who may provide assistance in diagnosing this problem.

***

Error:
Setup detected that the system file named [c:\windows\system32\blastcln.exe] is not signed properly
by Microsoft.  This file could not be restored to the correct Microsoft version.
Use the SFC utility to verify the integrity of the file.

***

Share this post


Link to post
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
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...