Jump to content

POSReady 2009 updates ported to Windows XP SP3 ENU


glnz

Recommended Posts

Heinoganda - You are correct that I have Avast Free on my XP machine (Dell Optiplex 755 desktop), and Avast is now

   Program version: 17.9.2322 (build 17.9.3761.0).

I updated Avast and I'm already fully updated with the above.

I have the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat with DWORD 0x0000000) (0)

My CPU is Intel Core 2 Duo E6850  @ 3.00GHz.

The yellow shield is prompting me to install KB4056615 and KB4056941.

so ----- DO it or DON'T do it?  (Why does that remind me of a high school girlfriend?)

Thanks.

Link to comment
Share on other sites


23 minutes ago, SD73 said:

Safe Mode did not update the Kernel files either....

Same for me.
I tried using the standalone installer, same result, and again in Safe Mode, same result.
:no:
I then tried the nuclear option of booting into Windows 8.1 (it's a dual boot machine) and manually substituting NTKRNLPA.EXE and NTOSKRNL.EXE in the \System32 folder with the (later) versions in the \DLLCache folder.
The result of that was that the machine wouldn't boot at all, just hanging on a black screen!
Don't know what to try next.
:(

Link to comment
Share on other sites

15 minutes ago, Dave-H said:

Same for me.
I tried using the standalone installer, same result, and again in Safe Mode, same result.
:no:
I then tried the nuclear option of booting into Windows 8.1 (it's a dual boot machine) and manually substituting NTKRNLPA.EXE and NTOSKRNL.EXE in the \System32 folder with the (later) versions in the \DLLCache folder.
The result of that was that the machine wouldn't boot at all, just hanging on a black screen!
Don't know what to try next.
:(

Well, at least you saved me some time trying to do the same dual boot trick since mine also has Linux.  I suppose we still have Patch Tuesday to look forward too.  I wonder how many others are having this problem but haven't noticed it yet?

And Dave, how is it you have a Kernel with a slightly higher version number than me?

 

Edited by SD73
Link to comment
Share on other sites

On my three computers, I had no problems installing KB4056941 and KB4056615. I can not retrace at the moment unfortunately. :(

Have you ever looked in the log files of KB4056941and KB4056615 or in the event viewer to see if they are noticeable?

:)

Link to comment
Share on other sites

8 minutes ago, heinoganda said:

On my three computers, I had no problems installing KB4056941 and KB4056615. I can not retrace at the moment unfortunately. :(

Have you ever looked in the log files of KB4056941and KB4056615 or in the event viewer to see if they are noticeable?

:)

Good idea.  Nothing unusual in the Event Viewer.  I looked for log files in the SoftwareDistribution folder pertaining to the failed KB4056615, but I couldn't find one.  Is there a specific place to check for KB related logs?

Link to comment
Share on other sites

Check C:\WINDOWS\KB4056615.log. If it contains messages like

c:\windows\system32\ntoskrnl.exe is in the list of oem drivers...skipping copy!
c:\windows\system32\ntkrnlpa.exe is in the list of oem drivers...skipping copy!

you can try running the KB .exe file with the /overwriteoem switch.

This could have unwanted consequences, so only try it if you have everything backed up and feel confident you are capable of recovering your system if there are problems!

I've never used this switch on a physical installation (because I've never had this issue occur), only for kernel updates in the VirtualBox VM I use for POSReady updates testing before applying them on my actual PC. While I haven't seen any problems resulting in the VM, that doesn't necessarily mean this is always safe. So, please don't take this as the recommended course of action, just something you can try if you're feeling adventurous.

Edited by mixit
Link to comment
Share on other sites

NTKRNLPA.EXE is the problem.

If I just manually substitute NTOSKRNL.EXE the system still boots fine.

I will do a grab of my Device Manager and check the log later on.

At first glance i don't think my problem machine has much in common with SD73's!

:yes:

Link to comment
Share on other sites

5 minutes ago, mixit said:

Check C:\WINDOWS\KB4056615.log. If it contains messages like


c:\windows\system32\ntoskrnl.exe is in the list of oem drivers...skipping copy!
c:\windows\system32\ntkrnlpa.exe is in the list of oem drivers...skipping copy!

you can try running the KB .exe file with the /overwriteoem switch.

This could have unwanted consequences, so only try it if you have everything backed up and feel confident you are capable of recovering your system if there are problems!

I've never used this switch on a physical installation (because I've never had this issue occur), only for kernel updates in the VirtualBox VM I use for POSReady updates testing before applying them on my actual PC. While I haven't seen any problems resulting in the VM, that doesn't necessarily mean this is always safe. So, please don't take this as a recommended course of action, just something you can try if you're feeling adventurous.

Yep, that's exactly what's in the log!
Will try using the over-ride switch later.

I do have an ISO backup!
:yes:

Link to comment
Share on other sites

9 minutes ago, Dave-H said:

Yep, that's exactly what's in the log!
Will try using the over-ride switch later.

I do have an ISO backup!
:yes:

I've got those in my log too!  I'll wait to see what happens AFTER Dave puts his toes in the water.

Link to comment
Share on other sites

34 minutes ago, Dave-H said:

If I just manually substitute NTOSKRNL.EXE the system still boots fine.

Sure. Because it's not used. Here's the scoop: your's is a multiprocessor machine. So, the files you need are ntkrnlmp.exe and ntkrpamp.exe.

However, it's not that simple... Windows is naughty and does not use those files with those names!  So make a copy of both to a temporary directory. Then rename ntkrnlmp.exe NTOSKRNL.EXE and ntkrpamp.exe NTKRNLPA.EXE. Now boot the other OS and substitute the namesakes of those renamed files by those renamed files in the %WINDIR%\SYSTEM32 directory. Now you may reboot and it should work. Good luck! :yes:

N.B.: the kernel actually used is NTKRNLPA.EXE. NTOSKRNL.EXE is just the fallback, so, when NTKRNLPA.EXE loads OK and checks as working, NTOSKRNL.EXE is not even loaded (which explains why when you substituted it by the wrong file nothing went wrong...) :angel

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