Recently my computer keeps ‘randomly’ getting BSOD over “termdd.sys” and “IRQL_NOT_LESS_OR_EQUAL”. Upon some research on “termdd.sys”, I noticed there’s a RDP heap corruption attack (https://securitynews.sonicwall.com/xmlpost/rdp-vulnerability-cve-2019-0708/) for RDP services.
In the past, I opened up my computer’s RDP service to the wild (bad practice) by routing the traffic to the right computer. The attempts did not successfully break into my computer, but in the process, these villains are corrupting my computer memory (heap) thus causing the BSOD.
Instead, I plugged the bad practice of opening up web services that are only for me to use. Instead connect to my home network using VPN when I need to access my computers. Since then the BSOD disappeared.
Lesson learned: Your computer is not hacked by a remote exploit (probably patched enough) doesn’t mean the exploit won’t trash your computer memory till it crashes. Better use a VPN than directly opening up RDP to the wild internet.
Windows has a path length limit that are typically at the order of 250 (260 for Windows 10) that’s a pain in the butt when moving files. Despite you can override it, it’s no fun when you copy a jillion files just to find out a few can’t make it because the path is too long and you have to find out which ones are not copied!
There’s a short command to check if the path exceed certain number of characters, which I recommend testing for 240 character so you can at least have a 10+ character folder on the root folder to put the files in:
powershell: cmd /c dir /s /b |? {$_.length -gt 240}
There are not many decent Cantonese IME around. The best option for Windows 7 and before are CPIME. It borderline worked for Windows 8/10 (desktop mode only), but I heard recently Windows 10 broke it in its 1903 update.
Dr. Choi kindly wrote another Cantonese IME called CAP, which I came across while looking for Cantonese IME for Linux. This is the only option that works with Windows 10 natively (apps and desktop).
Unfortunately the installer failed on a fresh Windows 10, saying that “CAP.dll” cannot be registered. I looked at the error code and it usually suggest a missing dependency for the DLL. I used Dependency Walker to look at what’s broken and noticed those are Visual C++ 2015 DEBUG runtime DLLs. Since debug builds aren’t suppose to have a redistributable runtime (it’s actually called NonRedist), the only solution is to install the community edition of Visual C++ 2015 to obtain these DLLs.
Note that “Common Tools for Visual C++ 2015” must be included (installed) so the IME won’t be broken (grayed):
The cause is the missing UCRTBASED.DLL. The files are located at:
C:\Program Files (x86)\Windows Kits\10\bin
It’s under the (x86) variant of Program Files regardless of whether it’s 32-bit or 64-bit.
The missing link to API-MS-WIN-CORE-PATH-L1-1-0.DLL is not important.
After you installed the IME after installing Visual C++ 2015 (any flavor, minimal is OK), you can remove Visual C++ 2015 without breaking the IME, EXCEPT you need to back up the UCRTBASED.DLL first and put it next to the core CAP.DLL file for the IME:
I have an ancient SONY NW-507 MP3 player (I still love it because of the 60hrs battery life) that the MP3 Manager software just interpret ANSI names encoded in the ID3 tag based on whatever system language the program started on.
I used to use AppLocale for that. There was a better variant called pAppLocale (or paip Applocale) but it’s no longer maintained anymore. Today I discovered a modern, much more powerful equivalent called Locale Emulator.
Microsoft Edge does default search provider is set using opensearch: you need to go to www.Google.com first before the Google option is available in the “Change Search Provider” lists. Otherwise all you’ll see is a disabled option
EasyBCD messes up the boot menu under UEFI. VisualBCD Editor is too low level. Use BootICE instead: it’s simple and free. It was designed for up to Windows 8.1, but it works for Windows 10.
Windows 10 cannot access network file shares of older Windows (7 and before) out of the box, and I’m not impressed that Microsoft let millions of users waste their productivity to figure it out.
The issue is caused by SMB negotiatons. Basically at the time of writing, there are 3 major versions of SMB:
More accurately, this blog post provides the negotiation chart for up to Windows 8 (think of Windows 10 is the same for now).
Turn on SMB 1.0 in newer Windows (8, 10 and above):
The SMB v1 does not have encryption, therefore a security risk. Makes sense to disable it unless there’s a compelling reason (like obsolete industrial computer under tightly controlled network).
SMB v2 might need to be enabled by registry in Windows 2008 if not already done so:
HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
SMB2 (DWORD): 1 for enable, 0 for disable
This web page tells you how to turn on/off each SMB version individually.
I tried Ubuntu on my old laptop, but it was unbearably much slower than that Windows 7 so I was looking for lightweight options. After some shopping, I settled on MX Linux as the drivers worked right of out the box for the hardware and it gave me the best user experience so far.
Other than responsiveness, the deciding factor that moves me away from Ubuntu is the amount work required to get the basic things working out of the box. Internationalization is almost fully configured in MX Linux, while I had to jump a few hoops to get the VL Gothic (Japanese) font in and struggled to get the IME to switch using Ctrl+Space / Ctrl+Shift (or any default shortcut keys) like in Windows. In MX Linux, they are the defaults right away.
I was really turned off by the fact that Ubuntu’s (minimal install) default Archive Manager is half-working out of the box: I get weird errors and partial success extracting RAR files because unrar was not installed by default! It just showed the lack of consideration about user experience.
MX Linux defaults to ibus, which works right out of the box with mozc (Japanese) language support. But I’d like to have a Cantonese IME that allows me to swear (the ibus-table-cantonese package was censored), so I opted for Andrew Choi’s CAP, which runs on fcitx. He used to have an iBus version, but it was a decade ago and I couldn’t get it to install.
Turns out it’s not that MX Linux is not that prepared when you want to use Fctix. None of the languages shows up when I tried to add an IME! After a lot of googling, I realized it requires im-config, and you need to install zenify before installing im-config!
After that fcitx works like a charm: mozc, CAP works in harmony, and I can turn the IME on/off by Ctrl+Space and switch between IMEs using Ctrl+Shift (just like in the old days)
EDIT: After all the praise I have on MX Linux. I noticed it overlooked something very basic! It does not make you configure timezone during setup and it’s not easy to change it! To do it the GUI way, first you have to go to “MX Time Settings”, and you have to type in the EXACT timezone string (TZ database name)! Geeze! It’s so caveman that we still have to do this in 2019!!
How did I noticed that I forgot to change the timezone? I realized the time in my Windows keeps getting changed (suspiciously a time-zone offset like difference) after I booted into MX Linux and boot back to Windows. That’s insidious!
I normally disable “Computer Browser” service in Windows by default because multiple computers having it on causes errors showing up in event log complaining there are multiple masters, and it’s not necessary for my simple home network because I’m just using a workgroup (no domain controller).
However, today I found out that even after setting up MX Linux’s Samba correctly (see below), if none of the computers on my windows network runs “Computer Browser”, my Windows computer name will not show up in “Thunar File Manager” although I can access it with smb://, and linux computers running Samba server shows up fine.
There’s also another twist to get the SMB client to work in Thunar File Manager. Despite smbtree works right out of the box (it detects the Windows shares), I’ll have to add this line in /etc/samba/smb.conf for the file manager to even probe the list of computers (not timeout):
name resolve order = bcast host
The point is to use broadcast lookup BEFORE dns lookup. DNS lookups for my local resources are often temperamental (could it be my router?), and I saw Linux Mint working with Windows briefly without these settings (editing smb.conf and also enabling “Computer Browser” service in Windows), but it failed today even after I re-installed MX Linux from scratch.
The other lines mentioned like client max protocol = NT1 and netbios name mentioned on the forums are not needed.
My sister’s computer is was infected with a bunch of stubborn malware. Even after cleaning the offending files, a lot of things won’t wouldn’t work.
Windows Update, run sfc /scannow, or DISM /Online /Cleanup-Image fails with unknown reasons, which I found it somehow related to “Windows Module Installer” service not running.
I saw something weird in services.msc: “Windows Module Installer” doesn’t exist, but I know the underlying name is “TrustedIntaller” and noticed a service named as such is there, but it cannot be started, nor there are any descriptive information.
So I searched registry for “TrustedInstaller” and got to its entry. I noticed these two:
It means the meaningful names and descriptions I saw on services.msc are generated by calling the underlying service executable file with switches. I checked my “C:\Windows\servicing” and found that “TrustedInstaller.exe” is not there at all! Of course you cannot start a service where the file does not exist at the promised path (ImagePath).
I searched the hard drive and found only one instance of the file stored somewhere (like C:\Windows\winsxs\x86_microsoft-windows-trustedinstaller_31bf3856ad364e35_6.1.7600.16385_none_90e389a7ae7a4b6c) and I tried to move the file to “C:\Windows\servicing”. However the ownership and permissions to write to “C:\Windows\servicing” goes to “TrustedInstaller” account, not “Administrator”, so I took the ownership, gave Administrator full rights, then move the file over.
Everything worked after that! Just the mere trick of deleting TrustedInstaller.exe is enough to make the user miserable trying to clean the system up! “sfc /scannow” or the like requires TrustedInstaller/WIM to be working in the first place, so you cannot use it to repair TrustedInstaller/WIM problems.
Turns out it is as easy as typing “shell:sendto” in the address bar of Windows Explorer. If I knew about it a decade ago, I would have used it more often.
