Windows Server may shut down if system time is wrong

I was testing some Reporting Services reports, but the test data was fairly old and some datasets were linked to the date, so I wasn’t getting proper results.

Instead of modifying the test data or the queries, the easy solution was to disable time synchronization and change the system time to 3 years in the past.

 

But changing the system time lead to an interesting problem:

Suddenly the server shut down automatically with no warning.

No chance was given to save open documents or to cancel shutdown.

 

I started up the virtual machine again and noticed that the system time had been reset.

Found this explanation for the behavior in Event Viewer:

Log Name:      System
Source:        User32
Date:          27-09-2013 11:14:19
Event ID:      1074
Task Category: None
Level:         Information
Keywords:      Classic
User:          SYSTEM
Computer:      TestServer
Description:
The process C:\Windows\system32\wlms\wlms.exe (TESTSERVER) has initiated the shutdown of computer TESTSERVER on behalf of user NT AUTHORITY\SYSTEM for the following reason: Other (Planned)
Reason Code: 0x80000000
Shutdown Type: shutdown
Comment: The license period for this installation of Windows has expired. The operating system is shutting down.

 

Be aware that Windows was activated and continued to be activated after it was restarted.

This happened with Windows Server 2012 R2 Standard, but I suspect it’s an issue with other versions and editions.

Conclusion

Apparently Windows doesn’t tolerate running with a wrong system time, even for testing purposes.

Fortunately wlms.exe is only present on evaluation versions of Windows, so this particular issue should never occur on production systems.

In any case, a correct system time is always desired for a number of things like logging dates, scheduling, synchronization, certificate validation and so on.

Laptop computer freezes when power supply is connected

I recently experienced a problem on a Lenovo Thinkpad T440p computer running Windows 10:

If the power supply was connected when the computer was running it would seemingly freeze: Mouse and keyboard became non-responsive.

However it was not a full freeze or crash, because music from a mediaplayer would continue.

If the power supply was disconnected, then the computer became responsive again.

 

One way to avoid the problem was to connect the power when the computer was sleeping or turned off.

 

It was an annoying problem and some people would assume the computer had crashed.

So I searched for a solution and found this:

https://www.ifixit.com/Answers/View/70872/How+to+fix+a+notebook+that+freezes+when+plugged+to+AC+power

 

The solution that worked for me was to:

  1. Open Device Manager
  2. Find Batteries -> Microsoft AC Adapter
  3. Right click and disable the Microsoft AC Adapter

2016-09-12_laptop_freezes_when_connected_to_power

Syntax errors due to wrong, but similar looking characters

I recently encountered problems when testing unattended Windows deployment.

A PowerShell script for setting up ShellLauncher did not seem to run.

 

Found this log message:

Encoding_issue_01

C:\Windows\system32>Powershell.exe –ExecutionPolicy RemoteSigned -NoProfile -NonInteractive c:\Install\PowerShell\ShellLauncher-setup.ps1
–ExecutionPolicy : The term '–ExecutionPolicy' is not recognized as the name of a cmdlet, function, script file, or ope
rable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again

 

This puzzled me because –ExecutionPolicy seemed correct.

 

When running the script manually from cmd.exe the cause of the problem became apparent:

Encoding_issue_02

ûExecutionPolicy : The term 'ûExecutionPolicy' is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again.

 

I examined which character was actually used instead of minus. It was – (en dash, 150) in Windows code page 1252 Latin 1 (ANSI).

PowerShell expects minus for options and interprets en dash as part of a cmdlet, function, script or program name.

 

Conclusion

No matter what code page and encoding is used many characters look similar to human eyes, but not to a computer.

If you encounter syntax problems for code or data that looks correct, I recommend checking the encoding and the actual character bytes with a hex editor.

Enable ClearType on Windows 10

I noticed jagged text on a computer running Windows 10.

It was particularly noticeable with Firefox and Chrome.

 

I opened Advanced display settings and tried to open ClearType text.

ClearType_01_Display_Settings

 

However this failed with this error message:

ClearType_02_Windows_cannot_access_cttune

C:\Windows\system32\cttune.exe

Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.

 

Instead I tried to start cttune.exe directly:

ClearType_03_Run_cttune

 

This was possible and I noticed that ClearType was disabled (as expected).

ClearType_04_ClearType_disabled

 

I selected: Turn on ClearType

ClearType_05_ClearType_enabled

 

And completed the guide to adjust ClearType optimally.

ClearType_06_Adjusting_ClearType

 

That solved the problem. After enabling and adjusting ClearType, text in all programs looked much better without jagged edges.

Error when exporting Hyper-V virtual machine to USB memory stick

Recently I needed to export a Hyper-V virtual machine to another computer.

I decided to export it directly to a USB memory stick.

However it failed consistently with this error message:

An_error_occured_while_attempting_to_export_the_virtual_machine

An error occurred while attempting to export the virtual machine.

Failed to copy file during export.

Failed to copy file from 'C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\DeploymentTest5New4.vhdx' to 'E:\VM\DeploymentTest5\Virtual Hard Disks\DeploymentTest5New4.vhdx': One or more arguments are invalid (0x80070057).

 

I examined the file system on the USB stick and discovered that it was FAT32.

FAT32 has a file size limitation of 4 GB.

Most virtual machines are likely to be bigger than that and that was also the case here.

 

I decided to empty the USB stick and reformat it to NTFS.

Then the virtual machine could be exported without problems.

Windows Task Manager may prevent safe removal of USB drive

I recently experienced problems removing a USB drive safely from a Thinkpad T440p running Windows 10.

I saw this warning:

Windows_is_unable_to_stop_the_device

Windows is unable to stop the device 'USB Mass Storage Device'. Don’t remove this device while it is still in use. Close any programs using this device and then remove it.

 

I checked if I was deliberately using any files or folders on the drive, but that was not the case.

 

I checked which processes held handles on the D: drive using the useful utility handle.

C:\bin\Handle>handle d:\

Handle v4.0
Copyright (C) 1997-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

System             pid: 4      type: File           FA0: D:\$Extend\$RmMetadata\$TxfLog\$TxfLog.blf
System             pid: 4      type: File          1788: D:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00000000000000000002
System             pid: 4      type: File          193C: D:\$Extend\$RmMetadata\$TxfLog\$TxfLogContainer00000000000000000001
System             pid: 4      type: File          1B60: D:\$Extend\$RmMetadata\$Txf

 

I found this in Event Viewer:

Log Name:      System
Source:        Microsoft-Windows-Kernel-PnP
Event ID:      225
Task Category: (223)
Level:         Warning
User:          SYSTEM
Description:
The application \Device\HarddiskVolume4\Windows\System32\Taskmgr.exe with process id 7432 stopped the removal or ejection for the device USB\VID_1058&PID_1023\57584C3145313145534A5A36.

 

The problem was solved by closing task manager. Then the USB drive could be removed safely.

AHCI power saving settings may cause system freezes

I experienced a frequent issue on a Lenovo Thinkpad T440p computer running Windows 10.

The system would sometimes become completely unresponsive for around 30 seconds, where every program would freeze.

Then the system would resume with very high disk activity for a while from the System and compressed memory process.

(Initially this made me suspect an issue with this process, but it seems like this was just a side effect)

 

In Event Viewer I found events like these around the time the freezes occured:

Log Name:      System
Source:        storahci
Event ID:      129
Description:
Reset to device, \Device\RaidPort0, was issued.

 

I found this blog post and discussion, which seems to have a solution and explanation:

Event ID 129 – storachi – Reset to device, DeviceRaidPort0, was issued.

 

The issue may be caused by AHCI power saving settings.

The simple workaround is to change the system power profile to High Performance under:

Control Panel -> Power Options

Power_Options_power_plan_High_performance

(This disables a number of power saving settings including one for AHCI)

 

Be aware that system freezes can also be caused by firmware bugs, driver bugs, defective SATA cable, failing harddisk/SSD and possibly other causes.

Deployment error: Windows could not create a partition

I recently encountered problems when deploying Windows (using AutoUnattend.xml) on a test machine.

Installation failed with the message:

Windows_could_not_create_a_partition_on_disk_0

Windows could not create a partition on disk 0. The error occured while applying the unattend answer file’s <DiskConfiguration> setting. Error code: 0x80042565

 

I found these errors in: X:\Windows\Panther\setuperr.log

CreatePartition: Disk 0 doesn't support creation of partitions of the specified type
ApplyDiskOperationUsingService: Failed to correctly apply disk operation of type [0x7]; hr = 0x80042565
CallBack_DiskConfiguration_ApplyUnattend:An error occurred while applying unattend disk configuration; hr = 0x80042565

 

The situation occured because the computer booted in BIOS mode, while the DiskConfiguration specified in AutoUnattend.xml was for UEFI.

(I suspect that similar problems will occur in the opposite situation)

When actively choosing UEFI in the boot menu, it worked as expected.

 

In Windows PE the firmware type can examined by checking the registry key:

HKLM\System\CurrentControlSet\Control\PEFirmwareType

 

If booting in a particular mode is desired, the deployment media can be modified to achieve this:

  • UEFI, not BIOS: Remove bootmgr file from media root.
  • BIOS, not UEFI: Remove efi folder from media root.

 

Discovered the details about identifying firmware type and enforcing booting from a particular firmware type in the article: WinPE: Boot in UEFI or legacy BIOS mode

Alt Gr key not working normally

If you use a Lenovo Thinkpad computer running Windows 10 you may experience a situation where the Alt Gr key stops working normally and just works as the regular Alt key.

Ctrl + Alt can be used as a substitute, but that’s only a workaround.

The problem seems to be related to the Synaptics Pointing Device driver.

 

The problem can be resolved for some time by reinstalling, rolling back or updating the Synaptics Pointing Device driver and then restarting the computer.

The problem can reappear after some weeks. However it can be resolved again by repeating the above steps.

If I discover a permanent fix, I will update the article again.

 

The driver can be rolled back this way:

1. Open Device Manager

2. Open Properties for Synaptics Pointing Device

Synaptics_Pointing_Device_01

3. Click: Rollback driver

Synaptics_Pointing_Device_02_Roll_Back_Driver

4. Restart the computer.

Run diskpart clean twice

When trying to clear a USB memory stick with diskpart I encountered this error:

DISKPART> clean

DiskPart has encountered an error: Access is denied.
See the System Event Log for more information.

 

The System event log contained this error from VDS Basic Provider:

Cannot zero sectors on disk \\?\PhysicalDrive2. Error code: 5@0101000F

 

The problem was solved simply by running clean again:

DISKPART> clean

DiskPart succeeded in cleaning the disk.

 

After that a partition could be created and formatted.

 

Warning: Always be very careful when using diskpart.

In order to avoid data loss make sure to list disks, select the correct disk and list disks again before running diskpart clean.