D
Daknut
Guest
POSSIBLE SOLUTIONS FOR THE 'HOST PROCESS FOR WINDOWS TASKS' CRITICAL EVENT IN RELIABILITY MONITOR
The Faulting Application Path is C:\Windows\System32\taskhostw.exe
The Application Name is taskhostw.exe
The Fault Module Name is unbcl.dll
Event ID 1000
Windows 10 - Version 1903
.oOo.
This has been partly taken from the Thread 'Host Process For Windows Taskhostw.exe Stopped Working: Event ID 1000' found here that DonT5 began on June 19 2019.
It appears that a great many individuals are experiencing the same repeated errors in Reliability Monitor but, as of yet, Microsoft have not provided a solution to my knowledge. This is an attempt to collate all the solutions that appear to have worked for people over the course of our discussions and bring them in to one place for ease of access, a 'digest' of solutions.
Some of these have worked for individuals and not for others - perhaps, sometimes, it's a few errors that need resolving and so the multitude of fixes is required. A couple of these may be putting right problems that are not related to the 'Host' error.
I am not overly technically minded so these instructions may seem simplistic but I have attempted to collate everything that we - and others - have tried, some of which are claimed to have worked (and which seem fairly safe to give a go).
It would be best if you read each solution first before attempting it to make sure you're happy with what you will be doing to your computer.
ONE
1. In the Search Window, type 'Powershell' until you get 'Windows Powershell'. Then right click on 'Windows Powershell' and left click on 'Run as Administrator'. When you get the command line, paste in or type the command (pay attention to the space):
sfc /scannow
The system is scanned. Once it completes, the new error we got was that there were problems that could not be resolved. It gives you a Windows path to a log (CBS.log) where it's been recorded. Go there and open the log file. At the very bottom of the text and scrolling up, you should see numerous errors relating to Windows Defender, stating that the back up image was also corrupt and could not over-write the problem files.
If that's the problem, then proceed with the following.
2. In the Serach Window, type 'Command Prompt' until you get 'Command Prompt'. Then right click on 'Command Prompt' and left click on 'Run as Administrator'. When you get the command line, paste in or type each of the commands, one by one, and let each one run to completion before beginning the next (again, pay attention to the spaces). Some of the processes seem to 'hang' after 100% is reached but be patient and wait:
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
This is telling the computer to use the online resources to clean up the system image that Powershell/scannow has just tried to use.
It take a few seconds for the percentage counter to begin. When it ends at 100%, WAIT. It looks like it's frozen but it will take a few minutes before it tells you that the process has been completed and a new command prompt appears (like it was in the beginning).
Close the window when completed.
3. WAIT a few minutes (some posters stated that they had to wait before the next would work. I have no idea why).
4. Now repeat point 1, EXCEPT that, at the end of the process, you should get a statement that the files were repaired/over-written.
5. Reboot the computer.
6. Run scannow once more and, this time, there should be nothing found.
This seems a strange way to resolve the original problem but it will resolve the problem with the Windows Defender files and scannow function. We observed this problem around a week after the original Host errors began.
Advice from Microsoft was to run with the error until a system update was released (which, at the time of writing, looks like it's still awaiting release). We never found that advice until after we'd fixed it!
TWO
Go to Event Viewer (Windows Key + X) then Windows Logs (on the left) and Application. Scroll down (in the middle) and see if you're getting ESENT errors (red circle, white x) with the ID Code 455.
If you are, go and find out the very first Host error you got and then go and see if the first ESENT error you got was within 12-24 hours prior to that time and date. There should be no Host errors prior to the first ESENT error.
I also looked at what .dlls taskhostw.exe accesses and one of them is the ESENT.dll - that's what made the connection with us at first. So, the solution to rectify the ESENT errors (and, hopefully, the Host errors, too):
Go to Windows\system32\config\systemprofile\AppData\Local\
Create the folder TileDataLayer then inside that folder create Database folder.
In effect, you've just made the directory (pay attention to the capitalisation):
C:\Windows\system32\config\systemprofile\AppData\Local\TileDataLayer\Database
The ESENT errors should stop immediately. A person who found the Windows Defender solution had worked, noted that the files were already present at the time of the scannow run *but* that the system modified one of the folders as part of that resolution. We thought that this could be why the solution worked for him but not for us.
THREE
A few people are suggesting that the problem is with .Net Framework (which is stated as being unable to be uninstalled in Windows 10. This isn't quite true as .Net Framework 3.5 can be while the current version as I type this is 4.8 and that cannot). Some have found this to be a solution, though.
In the search window, begin to type 'Turn Windows Features On or Off' and then select it.
Uncheck .Net framework 4.8 Advanced Services and allow the computer to make the changes.
Reboot. Recheck the item.
It's just a switch off and on again but - what the heck? - it's worth a go.
I tried something a bit different (and I doubt if it worked) - and it was also a tad dangerous. But, when you get to the check box as specified above, there is also a box for 3.5.
1. I accessed this Microsoft site and downloaded the Windows 7 utility that repairs .NET Framework. I expect that this repairs .Net Framework 3.5 but I wouldn't recommend using it - I am just recording the fact that I used it.
2. So, after repairing it, I uninstalled it - pretty stupid but that's exactly what I did.
In "Turn Windows features on or off" which is located in 'Programs and Features', untick both .Net Frameworks, then reboot. This uninstalls 3.5 but just switches 4.8 off.
I would have left it like this but something (undisclosed) needed 3.5 to run so I gave permission for it to be reinstalled. I left 4.8 unticked, though
(from here).
Again, there was no evidence that this worked in my own experience - but problems with .Net Framework have been suggested as being the cause and a couple of users elsewhere stated that this worked.
FOUR
One day (in a far away galaxy), I went back again to work out what I was doing when the Host error occurred. My Google History showed me that I'd just accessed an article to read 6 minutes prior - I had started to scroll through the first few paragraphs reading when the wife called me in to look at an error she was getting on her regular data back ups (more on that in a minute).
Five minutes after that, my Screen Saver kicked in and that's when the Host error took place. Now, my Screen Saver accesses a file in the Windows Directory that needs permission to copy in or delete from.
My wife's error, on the other hand, was just plain weird - it was the very same directory that my Screen Saver accesses (but on her computer, not mine) and it was the first time that that source of photos had been written to or deleted from for a fair few weeks - since before the Host errors had started occurring.
She got no sensible error message from the program but I copied the files manually to resolve the issue and the back up worked (albeit with no changes). It was only when I saw my error message at the time my Screensaver kicked in that I realised that the same folder could be responsible (access to a folder that has administrative permissions needed).
So, I stopped the Screensaver from starting up and made the computer switch the screen off after 5 minutes instead, going to Sleep after 15 minutes.
But I got another Host error two days later after 5 minutes when the screen switched off so I altered it to never switch off and kept it going to Sleep after 15.
This has seemed to be the final solution to end the Host errors but certainly to one cause of them. I'm currently in Day Two of the test period so a few more days free is required.
.oOo.
Other remedial action taken at some point in time during the above but I can't remember when:
a. Broken links to .dlls in the Registry can also throw up errors so I used a Registry Cleaner (Cache Cleaner) to rid myself of broken paths to files and programs that didn't exist. There were no references to the .dll file in the Registry - and there weren't any in the lines of code that were removed by Cache Cleaner.
b. Each and every time my wife's computer came out of hibernation one evening (after we had performed solution four above), the same Host error was popping up. It didn't seem to be associated with anything else so I changed the power plan not to include a Hibernation Option and the error messages stopped occurring that evening. These Host errors had occurred after having removed 'Turn On Fast Start Up' in the Power Settings (this was a different problem she was having with her battery life). The Host errors also popped up when waking from Sleep the following morning but seem to have been resolved when I turned 'Turn On Fast Start Up' back on. Some people have observed that having this 'On' is a cause of problems but I found it was being 'Off' that wasn't beneficial.
c. I noticed that, on my own computer, the NVIDIA and Intel Display drivers were way out of date and had not been automatically updated by the manufacturer's update program for a long time. The old ones were uninstalled and the new ones installed, not over-written. It has been suggested that out of date drivers could be the source of the Host errors.
.oOo.
It appears that either there are various solutions to the problem that people have been getting, various problems that need resolving or it could be that a solution has been assumed when one of the remedial actions has been tried (and either the trigger has not been pulled afterwards or something else minor was done that has actually sorted out the problem).
If you are still having the Host error message after doing the above then I'd suggest that the problem has something to do with a Program or App trying to access or write to a folder/file that is in a restricted area of the Hard Drive (like something in C:\Windows) that requires Administrative Access.
Even if it never required permission before, I'm guessing that something inadvertently changed in an update and that that is why the error messages are being thrown up. But the error doesn't seem to be consistently thrown up when the same action takes place - which makes trying to determine what it is rather difficult.
Finally, I have not seen anything recorded from Microsoft to acknowledge that there's a problem - even though there are a great many posts in different places outlining this error in reliability Monitor.
Lee
Continue reading...
The Faulting Application Path is C:\Windows\System32\taskhostw.exe
The Application Name is taskhostw.exe
The Fault Module Name is unbcl.dll
Event ID 1000
Windows 10 - Version 1903
.oOo.
This has been partly taken from the Thread 'Host Process For Windows Taskhostw.exe Stopped Working: Event ID 1000' found here that DonT5 began on June 19 2019.
It appears that a great many individuals are experiencing the same repeated errors in Reliability Monitor but, as of yet, Microsoft have not provided a solution to my knowledge. This is an attempt to collate all the solutions that appear to have worked for people over the course of our discussions and bring them in to one place for ease of access, a 'digest' of solutions.
Some of these have worked for individuals and not for others - perhaps, sometimes, it's a few errors that need resolving and so the multitude of fixes is required. A couple of these may be putting right problems that are not related to the 'Host' error.
I am not overly technically minded so these instructions may seem simplistic but I have attempted to collate everything that we - and others - have tried, some of which are claimed to have worked (and which seem fairly safe to give a go).
It would be best if you read each solution first before attempting it to make sure you're happy with what you will be doing to your computer.
ONE
1. In the Search Window, type 'Powershell' until you get 'Windows Powershell'. Then right click on 'Windows Powershell' and left click on 'Run as Administrator'. When you get the command line, paste in or type the command (pay attention to the space):
sfc /scannow
The system is scanned. Once it completes, the new error we got was that there were problems that could not be resolved. It gives you a Windows path to a log (CBS.log) where it's been recorded. Go there and open the log file. At the very bottom of the text and scrolling up, you should see numerous errors relating to Windows Defender, stating that the back up image was also corrupt and could not over-write the problem files.
If that's the problem, then proceed with the following.
2. In the Serach Window, type 'Command Prompt' until you get 'Command Prompt'. Then right click on 'Command Prompt' and left click on 'Run as Administrator'. When you get the command line, paste in or type each of the commands, one by one, and let each one run to completion before beginning the next (again, pay attention to the spaces). Some of the processes seem to 'hang' after 100% is reached but be patient and wait:
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
This is telling the computer to use the online resources to clean up the system image that Powershell/scannow has just tried to use.
It take a few seconds for the percentage counter to begin. When it ends at 100%, WAIT. It looks like it's frozen but it will take a few minutes before it tells you that the process has been completed and a new command prompt appears (like it was in the beginning).
Close the window when completed.
3. WAIT a few minutes (some posters stated that they had to wait before the next would work. I have no idea why).
4. Now repeat point 1, EXCEPT that, at the end of the process, you should get a statement that the files were repaired/over-written.
5. Reboot the computer.
6. Run scannow once more and, this time, there should be nothing found.
This seems a strange way to resolve the original problem but it will resolve the problem with the Windows Defender files and scannow function. We observed this problem around a week after the original Host errors began.
Advice from Microsoft was to run with the error until a system update was released (which, at the time of writing, looks like it's still awaiting release). We never found that advice until after we'd fixed it!
TWO
Go to Event Viewer (Windows Key + X) then Windows Logs (on the left) and Application. Scroll down (in the middle) and see if you're getting ESENT errors (red circle, white x) with the ID Code 455.
If you are, go and find out the very first Host error you got and then go and see if the first ESENT error you got was within 12-24 hours prior to that time and date. There should be no Host errors prior to the first ESENT error.
I also looked at what .dlls taskhostw.exe accesses and one of them is the ESENT.dll - that's what made the connection with us at first. So, the solution to rectify the ESENT errors (and, hopefully, the Host errors, too):
Go to Windows\system32\config\systemprofile\AppData\Local\
Create the folder TileDataLayer then inside that folder create Database folder.
In effect, you've just made the directory (pay attention to the capitalisation):
C:\Windows\system32\config\systemprofile\AppData\Local\TileDataLayer\Database
The ESENT errors should stop immediately. A person who found the Windows Defender solution had worked, noted that the files were already present at the time of the scannow run *but* that the system modified one of the folders as part of that resolution. We thought that this could be why the solution worked for him but not for us.
THREE
A few people are suggesting that the problem is with .Net Framework (which is stated as being unable to be uninstalled in Windows 10. This isn't quite true as .Net Framework 3.5 can be while the current version as I type this is 4.8 and that cannot). Some have found this to be a solution, though.
In the search window, begin to type 'Turn Windows Features On or Off' and then select it.
Uncheck .Net framework 4.8 Advanced Services and allow the computer to make the changes.
Reboot. Recheck the item.
It's just a switch off and on again but - what the heck? - it's worth a go.
I tried something a bit different (and I doubt if it worked) - and it was also a tad dangerous. But, when you get to the check box as specified above, there is also a box for 3.5.
1. I accessed this Microsoft site and downloaded the Windows 7 utility that repairs .NET Framework. I expect that this repairs .Net Framework 3.5 but I wouldn't recommend using it - I am just recording the fact that I used it.
2. So, after repairing it, I uninstalled it - pretty stupid but that's exactly what I did.
In "Turn Windows features on or off" which is located in 'Programs and Features', untick both .Net Frameworks, then reboot. This uninstalls 3.5 but just switches 4.8 off.
I would have left it like this but something (undisclosed) needed 3.5 to run so I gave permission for it to be reinstalled. I left 4.8 unticked, though
(from here).
Again, there was no evidence that this worked in my own experience - but problems with .Net Framework have been suggested as being the cause and a couple of users elsewhere stated that this worked.
FOUR
One day (in a far away galaxy), I went back again to work out what I was doing when the Host error occurred. My Google History showed me that I'd just accessed an article to read 6 minutes prior - I had started to scroll through the first few paragraphs reading when the wife called me in to look at an error she was getting on her regular data back ups (more on that in a minute).
Five minutes after that, my Screen Saver kicked in and that's when the Host error took place. Now, my Screen Saver accesses a file in the Windows Directory that needs permission to copy in or delete from.
My wife's error, on the other hand, was just plain weird - it was the very same directory that my Screen Saver accesses (but on her computer, not mine) and it was the first time that that source of photos had been written to or deleted from for a fair few weeks - since before the Host errors had started occurring.
She got no sensible error message from the program but I copied the files manually to resolve the issue and the back up worked (albeit with no changes). It was only when I saw my error message at the time my Screensaver kicked in that I realised that the same folder could be responsible (access to a folder that has administrative permissions needed).
So, I stopped the Screensaver from starting up and made the computer switch the screen off after 5 minutes instead, going to Sleep after 15 minutes.
But I got another Host error two days later after 5 minutes when the screen switched off so I altered it to never switch off and kept it going to Sleep after 15.
This has seemed to be the final solution to end the Host errors but certainly to one cause of them. I'm currently in Day Two of the test period so a few more days free is required.
.oOo.
Other remedial action taken at some point in time during the above but I can't remember when:
a. Broken links to .dlls in the Registry can also throw up errors so I used a Registry Cleaner (Cache Cleaner) to rid myself of broken paths to files and programs that didn't exist. There were no references to the .dll file in the Registry - and there weren't any in the lines of code that were removed by Cache Cleaner.
b. Each and every time my wife's computer came out of hibernation one evening (after we had performed solution four above), the same Host error was popping up. It didn't seem to be associated with anything else so I changed the power plan not to include a Hibernation Option and the error messages stopped occurring that evening. These Host errors had occurred after having removed 'Turn On Fast Start Up' in the Power Settings (this was a different problem she was having with her battery life). The Host errors also popped up when waking from Sleep the following morning but seem to have been resolved when I turned 'Turn On Fast Start Up' back on. Some people have observed that having this 'On' is a cause of problems but I found it was being 'Off' that wasn't beneficial.
c. I noticed that, on my own computer, the NVIDIA and Intel Display drivers were way out of date and had not been automatically updated by the manufacturer's update program for a long time. The old ones were uninstalled and the new ones installed, not over-written. It has been suggested that out of date drivers could be the source of the Host errors.
.oOo.
It appears that either there are various solutions to the problem that people have been getting, various problems that need resolving or it could be that a solution has been assumed when one of the remedial actions has been tried (and either the trigger has not been pulled afterwards or something else minor was done that has actually sorted out the problem).
If you are still having the Host error message after doing the above then I'd suggest that the problem has something to do with a Program or App trying to access or write to a folder/file that is in a restricted area of the Hard Drive (like something in C:\Windows) that requires Administrative Access.
Even if it never required permission before, I'm guessing that something inadvertently changed in an update and that that is why the error messages are being thrown up. But the error doesn't seem to be consistently thrown up when the same action takes place - which makes trying to determine what it is rather difficult.
Finally, I have not seen anything recorded from Microsoft to acknowledge that there's a problem - even though there are a great many posts in different places outlining this error in reliability Monitor.
Lee
Continue reading...