Jump to content

KB919007 Failed


Wijono

Recommended Posts

I have another weird situation, when trying to implement KB919007 patch for WinXP SP2, as soon as I double-click the <WindowsXP-KB919007-x86-ENU.exe>, the screen goes black and the PC start to reboot itself.

Anyone has the same experience and know how to work around it?

Link to comment
Share on other sites


Till now I am still having this problem unsolved.

To shed a little bit more light, I turn off “Automatically restart” in the “Startup and Recovery” box.

I double-clicked the <WindowsXP-KB919007-x86-ENU.exe>, then it did not restart, but a BSOD instead with following message:

STOP: 0x0000008E (0xC0000005, 0xEFECDBEF, 0xEF4F4A20, 0x00000000)

I searched the web and found the most probable cause could be either Graphics (Video) card or RAM. I tried different drivers for the video cards, situation unchanged.

I tested my RAM with MemTest, also nothing wrong with the RAM.

Anyway, this problem of PC rebooting itself only happens with <WindowsXP-KB919007-x86-ENU.exe>, nothing else!! Other Windows Updates run well. I have the feeling it could not be the video card or RAM, otherwise it will also happen with other programs, right?

Any help will be highly appreciated.

Link to comment
Share on other sites

After reading what KB919007 is supposed to fix, it related to some PGM service -

The MSMQ service, which is the Windows service needed to allow PGM communications is not installed by default
Pragmatic General Multicast (PGM) is only supported when Microsoft Message Queuing (MSMQ) 3.0 is installed. The MSMQ service is not installed by default.
If you do not have this service installed, or have it installed but disabled since it is of no use to you, then you are not affected by the vulnerability at all and there is no need to install KB919007. Edited by LLXX
Link to comment
Share on other sites

Thanks to LLXX for the effort to help.

As a matter of fact I have done a manual trick to install that update by copying file and folders from another PC where KB919007 was successful before as follows:

1. copy <rmcast.sys> into the folders <C:\WINNT\system32> and <C:\WINNT\system32\dllcache>

2. copy <$NtUninstallKB919007$> into the folder <C:\WINNT>

3. copy folder <KB919007> into the folder <C:\WINNT\$hf_mig$>

Having done that, even “Microsoft Baseline Security Analyzer 2.0” does recognized as if KB919007 is already implemented, hence not necessary anymore.

However, I still feel not comfortable, something in my PC may still be wrong so that implementing KB919007 directly will result in reboot. Would make me happy if I could have solved that problem.

Link to comment
Share on other sites

Meanwhile I found additional information, that this behavior takes place each time I try to implement Windows Update (KB######) with the file size less than 1MB, e.g., WindowsXP-KB925486-x86-ENU.exe which is 784KB, once I double-click that file, Windows reboot right away. When the file size is exceeding 1MB then it is no problem. It is also no problem with .NET update even with less than 1MB. What could possibly be the cause? Incompatibility of Windows Installer and those KB######? Any corrupted system files? Hope some experts in this Forum could help me. Thanks a lot!!

Link to comment
Share on other sites

In pursue of the solution to this problem, I think I am one step ahead now.

I do the extraction of the problem updater in a good PC by double-clicking the updater, then stop at the “Software Update Installation Wizard” popup, copy all the extracted files into the problematic PC, double-click the <update.exe>, the update is implemented flawlessly in the problem PC. That way I could do the KB919007, KB 923414, KB925486 and KB922819 (All less than 1MB).

With other words, the offending part is the extraction part. Could someone help me to tell what system file(s) is used in the extraction part of the Windows Updater please?

Link to comment
Share on other sites

Run MemTest86+ on your machine for a few hours to test the RAM. You might not have run it long enough the first tiem.

Decompression errors usually occur because of hardware faults.

Edited by LLXX
Link to comment
Share on other sites

Thanks a lot LLXX, so far you are the only one that try to help.

You may be right, the fault may be in the direction of memory. As I have mentioned in another thread on this problem, in the Device Manager > System devices > System board Properties, under the Resource settings I see two unwanted Memory Range (not there in the same type of good PC):

- Memory Range: 000C0000

- Memory Range: 000F0000

Those might be left by trojan or virus? The size of that memory range is just enough for program that is less than 1MB, but as it is not existing Windows crashed when trying to use it.

The problem now is how can I get rid of them.

Thanks a lot again.

Link to comment
Share on other sites

No, the CPU is not overclocked.

This is the PC with weird folder as I have described in following thread:

http://www.msfn.org/board/index.php?showtopic=84816

That means, it really is related to virus/trojan Haxdoor as I have suspected before. My suspicion is confirmed by this Microsoft Knowledge Base:

http://support.microsoft.com/kb/903251/en-us

I will try to fix the problem and post the result here. Hopefully I will not have to reinstall the operating system.

Basically I am not comfortable using "Windows Recovery Console". Is there a way to delete running process by first "killing" it?

Link to comment
Share on other sites

Basically I am not comfortable using "Windows Recovery Console". Is there a way to delete running process by first "killing" it?
Then get used to using the recovery console if you want to fix your problem. You could try taskkill from the command prompt, but seeing as this is a rootkit-type of virus, I doubt that will have any effect; hence, the recovery console.
Link to comment
Share on other sites

  • 4 weeks later...

Finally I have gone the Recovery Console way.

A few Haxdoor Rootkits have been deleted according to the following MS KB:

http://support.microsoft.com/kb/903251/en-us

But in the Device Manager > System devices > System board Properties, under the Resource settings I still see two unwanted Memory Range (not there in the same type of good PC):

- Memory Range: 000C0000

- Memory Range: 000F0000

As such the BSOD problem is not solved yet.

How can I fix that problem other than reinstalling Windows XP?

Any hint or help will be highly appreciated.

Link to comment
Share on other sites

I was drawing conclusion too fast before. When I saw following in the System Information -> System Summary -> Hardware Resources -> Conflicts/Sharing:

Memory Address 0xC0000-0xCBFFF System board

Memory Address 0xC0000-0xCBFFF PCI bus

Memory Address 0xF0000-0xFFFFF System board

Memory Address 0xF0000-0xFFFFF PCI bus

I assumed that there are still conflicts that may induce the BSOD for the Windows Update <WindowsXP-KB919007-x86-ENU.exe> and all other updates with file size smaller then 1MB as I experienced it before.

I was wrong though, after the cleaning with Recovery Console, I can now run <WindowsXP-KB919007-x86-ENU.exe> and all other updates with file size smaller then 1MB with no BSOD anymore. With other words [http://support.microsoft.com/kb/903251/en-us] was successfully implemented in my case!

I am forced now to believe, that those Memory Address pair above are not conflicts but rather sharing perhaps. Can someone help me to find out more about that?

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...