I am trying to troubleshoot a Windows 10 Pro system. This is complicated by the fact that the system event log is flooded by a set of identical information level messages about TPM every minute.
The messages are:
The TPM has been cleared. Reason: ByPPI.
The Ownership of the Trusted Platform Module (TPM) hardware on this computer was
successfully taken (TPM TakeOwnership command) by the system.
The TBS device identifier has been generated.
The TPM was successfully provisioned and is now ready for use.
I found a TPM-Maintenance task in the task scheduler that seems to run every minute.
Can someone explain why Windows is clearing the TPM once a minute? Is that necessary? Can I safely disable the TPM-Maintenance task to prevent this flood of messages?
Thanks!
Related
It seems to happen every couple months or so and while it auto-recovers on its own usually within ~10 minutes I'd still like to find out how to change the Windows Update schedule since it frequently occurs during business hours.
We have several web apps in various Azure subscriptions, and they all behave this way. Once we get a notification that one goes down, the others usually go down over the next few days/week.
I used remote desktop to view the Event Viewer for the web role and see the following (this down time took place between 9:48am and 10:02am on the east coast, so definitely not ideal):
8/6/2020 1:48:15 PM - "Automatic Updates is now paused."
Followed by several services stopping, and then:
8/6/2020 1:52:53 PM - "The process C:\43..61\Setup.exe (RD..33) has initiated the restart of computer RD..3 on behalf of user NT AUTHORITY\SYSTEM for the following reason: Other (Planned)
Reason Code: 0x80000000
Shutdown Type: restart
Comment: "
8/6/2020 1:52:53 PM - "Automatic Updates is now resumed."
8/6/2020 1:53:10 PM - "The operating system is shutting down at system time 2020-08-06T13:53:10.614704600Z."
8/6/2020 1:53:12 PM - The operating system started at system time 2020-08-06T13:53:12.487679900Z.
Obviously it takes a while for everything to come back up, and I finally get notified that the site is back up about 9 minutes later.
Is there a way to specify when the Windows Updates should take place?
I can tell you clearly that it is not possible to schedule windows updates.
The windows update in this cloud services is about once a month. The time is not fixed. There is no way to control this.
Azure Guest OS releases and SDK compatibility matrix
solution:
We can create 2 webroles so that we can solve the situation that the program is closed due to windows update.
principle:
Create 2 webroles to load balance the server pressure. When the windows is updated, it will not be updated at the same time, but a planned instance update ends, and the next instance update is performed.
In this way, as long as you create >=2 webrols, there will be 2 instances, so that the program can guarantee that it will not stop due to updates.
I want to create an Azure Virtual Machine that I only need to run approximately for 1 or 2 hours once or twice per day. I don't want to pay for the server when I'm not using it.
I know I can just go to the dashboard and shut it off, but I often forget to do so, I'm getting senile! I would like for a timer to start when the system (Windows 10) is started, and when the timer reaches zero, the image is made inactive (no charges incurred) unless I request more time.
Any ideas would be appreciated.
The dashboard has an automatic shutdown feature. This can also be configured to send a webhook notification with a link which will delay the shutdown. Currently in-machine notifications are not supported.
Although there are many tools like PowerShell scripts and apps that you could use from within the VM to trigger automatic shutdown, there are some billing gotchas to be aware of.
With an Azure VM, you pay per second and cease paying only when the machine is completely deallocated and no longer reserving memory and cores on the platform. (There is still a nominal storage charge associated with storage of the VM image). You cannot deallocate the VM from within itself.
To ensure the VM isn't incurring charges, check that the status is 'Stopped (deallocated').
I've got the following totally reproducible scenario, which I'm unable to understand:
There is a very simple application, which does nothing else than calling CreateObject("Word.Application"), that is creating an instance of MS Word for COM interop. This application is located on a Windows Terminal Server. The test case is to connect via RDP, execute the application and the application will output the time taken for the CreateObject call.
The problem now is that the execution time is significantly longer, if I connect from a specific notebook (HP Spectre): It takes 1,7s (+/- 0.1s).
If I connect from any other machine (notebook or desktop computer), then the execution time is between 0,2-0,4s.
The execution times don't depend on the used RDP account, or screen resolution, or local printers. I even did a fresh install of Windows on that HP notebook to rule out any other side-effects. It doesn't matter if the HP notebook is connected via WLAN or an USB network card. I'm at a loss understanding the 4x to 8x execution time difference to any other machine.
Which reason (component/setting) could explain this big difference in execution time?
Some additional information: I tried debugging the process using an API monitor and could see that >90% of the execution time is actually being spent between a call to RpcSend and RpcReceive. Unfortunately I can't make sense of this information.
It could be the credential management somehow being in the way.
Open the .rdp file with notepad and add
enablecredsspsupport:i:0
This setting determines whether RDP will use the Credential Security Support Provider (CredSSP) for authentication if it is available
Related documentation
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff393716%28v%3dws.10%29
According to your information about RpcSend and RpcReceive time consumption, it could be the case you have some service stopped on your client machine, like DCOM server or some other COM-related (they usually have "COM" or "transaction" in their names).
Some of that services could be started/stopped (if Manually mode selected) by system to/after transfer your request, but there is a time delay to starting service.
I suggest you to open Computer Management - Services or run -> services.msc and compare COM-related services running on your "slow" client and on your "fast" clients, and try to set Automatically running instead Manually or Disabled.
Also, try to run API Monitor on such processes to determine the time-consuming place more precisely.
I have a strange problem which occurs only with some specific Windows versions (unfortunately I do not have such a Windows variant but only bug reports from a user which can see this problem).
What I'm doing: I send data via TCP/IP from a client application (on a PC) to an embedded device. This is a continuous stream of data out of one threads context and here always a bunch of data are collected so that the packages have a size of a bit less of multiples of 1460 bytes to have as most as effective TCP-packets.
Now a stop-condition can occur, where one has to react immediately. In this case an other TCP-package is sent to the device using the same network connection but out of an other thread. This package contains a payload of only a few bytes but is sent 3..4 times to ensure reaction of the device.
Both threads use the same sending-function, but it is locked by a mutex so that no concurrent accesses can happen.
Now following problem occurs on this one users PC: when stop-packages have been sent, all following send-attempts to the same socket fail with a system error code of 10054 (remote end hung up). Amazingly the log files of the embedded device clearly say the connection was not closed by it.
Since I can't reproduce this problem, I stab in the dark here.
The problem appears only on this users Windows 7, it does not happen with Linux or with my Windows versions (including a Windows 7). Thus any idea/suggestion/comment is welcome: are there any bugs/conditions known where a Windows TCP/IP connection can fail in this way?
Thanks for every comment and idea!
I'm very interested in the answer to another question regarding watchdog timers for Windows services (see here). That answer stated:
I have also used an internal watchdog system running in another thread. That thread looks at the main thread for activity like log output or a toggling event. If the activity is not seen then the service is considered hung and I shutdown the service.
In this case you can configure windows to auto-restart a stopped service and that might clear the problem (as long as it's not an internal logic bug).
Also services I work with have text logs that are written to a log. In addition for services that are about to "sleep for a bit", I log the time for the next wake up. I use MTAIL to watch a log for output."
Could anyone give some sample code how to use an internal watchdog running in another thread, since I currently have a task to develop a windows service which will be able to self restart in case it failed, hung up, etc.
I really appreciate your help.
I'm not a big fan of running a watchdog as a thread in the process you're watching. That means if the whole process hangs for some reason, the watchdog won't work.
Watchdogs are an idea lifted from the hardware world and they had it right. Use an external circuit as simple as possible (so it can be provably correct). Typical watchdogs simply ran an timer and, if the process hadn't done something before the timer expired (like access a memory location the watchdog was watching), the whole thing was reset. When the watchdog was "kicked", it would restart the timer.
The act of the process kicking the watchdog protected that process from summary termination.
My advice would be to write a very simple stand-alone program which just monitored an event (such as file update time being modified). If that event didn't occur within the required time, kill the process being watched (and let Windows restart it).
Then have your watched program periodically rewrite that file.
Other approaches you might want to consider besides regularly modifying the lastwritetime of a file would be to create a proper performance counter or even a WMI object. We do the later in our build infrastructure, the 'trick' is to find a meaningful work unit in the service being monitored and pulse your 'heartbeat' each time a unit is finished.
The advantage of WMI or Perf Counters over a the file approach is that you then become visible to a whole bunch of professional MIS / management tools. This can add a lot of value.
You can configure from service properties to self restart in case of failure
Services -> right-click your service -> Properties -> First failure : restart the service -> Second failure : restart the service -> Subsequent failure : restart