glnz Posted January 6, 2018 Author Share Posted January 6, 2018 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 More sharing options...
SD73 Posted January 6, 2018 Share Posted January 6, 2018 Safe Mode did not update the Kernel files either.... Link to comment Share on other sites More sharing options...
heinoganda Posted January 6, 2018 Share Posted January 6, 2018 (edited) @glnz Just download Malwarebytes and copy it to another folder. If that works, I would risk it. Edited January 6, 2018 by heinoganda Link to comment Share on other sites More sharing options...
Dave-H Posted January 6, 2018 Share Posted January 6, 2018 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. 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 More sharing options...
SD73 Posted January 6, 2018 Share Posted January 6, 2018 (edited) 15 minutes ago, Dave-H said: Same for me. I tried using the standalone installer, same result, and again in Safe Mode, same result. 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 January 6, 2018 by SD73 Link to comment Share on other sites More sharing options...
heinoganda Posted January 6, 2018 Share Posted January 6, 2018 (edited) @Dave-H @SD73 There seems to be an incompatibility of the kernel with hardware. Will try on various hardware. A hardware list would be an advantage, maybe there similarities which point to the problem. Edited January 6, 2018 by heinoganda Link to comment Share on other sites More sharing options...
SD73 Posted January 6, 2018 Share Posted January 6, 2018 Good observation, heinoganda. I'm running a Dell Inspiron that's about 10 years old. It's a model 530s w/dual processors - Pentium Dual CPU E2180 @ 2.00GHz. Link to comment Share on other sites More sharing options...
heinoganda Posted January 6, 2018 Share Posted January 6, 2018 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 More sharing options...
SD73 Posted January 6, 2018 Share Posted January 6, 2018 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 More sharing options...
heinoganda Posted January 6, 2018 Share Posted January 6, 2018 1 minute ago, SD73 said: Is there a specific place to check for KB related logs? In %windir% or C:\Windows. Link to comment Share on other sites More sharing options...
mixit Posted January 6, 2018 Share Posted January 6, 2018 (edited) 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 January 6, 2018 by mixit Link to comment Share on other sites More sharing options...
Dave-H Posted January 6, 2018 Share Posted January 6, 2018 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! Link to comment Share on other sites More sharing options...
Dave-H Posted January 6, 2018 Share Posted January 6, 2018 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! Link to comment Share on other sites More sharing options...
SD73 Posted January 6, 2018 Share Posted January 6, 2018 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! 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 More sharing options...
dencorso Posted January 6, 2018 Share Posted January 6, 2018 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! 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...) 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now