Category: Windows

I just noticed there’s a new context menu item when I right click on my folders:

WTF is Catch!? After some Google search, it seems like it’s something that has to do with Daemon Tools. I do not recall installing such thing, went to Daemon Tools Lite’s settings, and found Catch! in there and it was enabled. I immediately disabled it:

NOT COOL Disc Soft! It’s not even free software. I paid for it. Here’s their serious offenses:

• Pushing software features (enabling by default) without giving ample notice to users
• The feature involves adding security risks such as opening ports and sharing files (ok if the users are aware of their presence)
• Intruding user attention space by taking up a space in their file context menu.

And finally, the FUCKING uninformative name like “Catch!”. Who the fuck do you think you are Disc Soft! Nobody knows its your fucking product as part of Daemon Tools Lite if you silently sneak it in and the name shows up on the context menu! You think you are the Redmond demon who has abusive powers over their PAID customers! It’s almost handled like bloatware.

Even worse, the name “Catch!” is fucking generic that it’s hard to get specific result in web search. I’m writing the blog post so that if I came across that again, I don’t have to do the research all over again.

 58 total views,  1 views today

I’ve recently closed my Microsoft account (finding big tech too intrusive and too eager to make users subjects of their social experiments, aka data harvesting) and do not want Windows to link to it.

After tons of research on forums, I’ve found that Microsoft removed “Sign in with a local account instead” button/link in “Settings->Accounts->Your Info” page since 2017. So this method won’t work anymore:

So far nobody offered a solution that does not involve starting over with a new local account, but in involves moving your user specific settings and desktop folders, which is a pain in the butt.

After exhausting publicly available avenues so that I’m not reinventing the wheel, I decided to go back to first principles trying to ‘crack the code’. The first thing I thought of, based off my intuition about Windows system since middle school, is to search for my associated Microsoft Account ID (the email account string) in the registry. Turns out it only appears only in two keys (branches):

#1: HKEY_CURRENT_USER\Software\Microsoft\IdentityCRL\UserExtendedProperties\{Microsoft ID}

#2: HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\StoredIdentities\{Microsoft ID}
#3: HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\StoredIdentities\{Microsoft ID}\{SID}

Replace {Microsoft ID} with your Microsoft (Web) Account Email address. {SID} is the security identifier of the underlying local/domain user account (starts with “S-1-” followed by a long string of numbers with dashes)

If your Microsoft (Web) account is associated with only one local/domain account (SID), simply delete the two registry branches (called keys) #1 and #2 that ends with your {Microsoft ID}. The line #3 is just a sub-key (sub-folder/ranch) under line #2, so if you delete the whole line #2 branch, the rest below it is gone.

Given the registry key structure, I’d anticipate that if you have associated the same {Microsoft ID} to a few windows local/domain accounts, and only wanted to just break its link to specific local/domain accounts without affecting the rest, you might want to just get rid of this

HKEY_USERS\.DEFAULT\Software\Microsoft\IdentityCRL\StoredIdentities\{Microsoft ID}\{SID}

instead of the first two registry paths that covers information about the {Microsoft ID} unrelated to the local/domain account. To find out which {SID} refers to the local/domain account you want to delete, go to command prompt and type this

WMIC useraccount get name,sid

and it will show you a table that maps your Windows local/domain account name to SIDs so you can pick out the right registry key path (#3) to delete.

Of course, after you’ve deleted the last SID associating {Microsoft ID} on your computer, you might as well delete all references to the {Microsoft ID} to avoid orphan registry keys that confuse people.

 53 total views,  1 views today

My web hosting package comes with cPanel email, which comes with Calendar/Tasks (CalDAV) and Contact list (CardDAV) in one convenient package.

Default setup often causes a few user experience problem

• Special storage folders not working (hint: path incorrect)
• Sent email not saved in ‘Sent’ folder

Turns out that every ISP has their own IMAP folder structure. My ISP structured everything, from system special folders (Sent, Drafts, Trash, Spam) to user-defined folder, into subfolders under Inbox.

So the settings in Windows Live Mail should be:

DO NOT FORGET to set the root folder Inbox! Subfolders are internally accessed as Inbox.Sent, Inbox.Drafts, etc. Using DOT (.) as seperator! Do not use slash like Gmail. It doesn’t work!

If you specify the “Root folder path” and have the special folders relative to that, the Windows Live Mail client will show a flat layout (Just like the webmail client):

Alternatively, I tried entering the special folders’s full path individually one by one

but I’m pleased to see that doing so VISUALLY placed ALL folders (system or use-created) into a nice tree structure that follows its native structure!

Having a root folder “Inbox” implied a prefix “Inbox.” (with the dot at the end) to all special folders path. Again, slash do not work as it’s not Gmail. The separator is dot in cPanel.

Seems like the whether ‘Root folder path‘ is specified determines if the folders are flattened or have the native tree structure in Windows Live Mail’s display.

Special folders settings can be invalid, which the Windows Live Mail Client will quietly ignore them and operate in local storage folders instead.

How did I discovered it? I saw the tool-tip INBOX.sent when I hover over the ‘Sent’ folder in Horder WebMail.

 73 total views

Many years ago, Gmail changed their folder structure so some of the IMAP settings tutorials are not correct anymore. Since Windows Live Mail (WLM) auto-configures Gmail, the special folders are automatically determined and they cannot be specified. Please leave Root folder path alone like this:

Basically Gmail decided with the exception of Inbox, which stays at root, all “System labels” goes under the subfolder [Gmail]. However user-created labels (simply called “Labels“) stay at root folder level. For example, I have a user folder called Save enabled for IMAP, the folder tree with the Gmail account looks like this:

Because you cannot specify where the Trash folder is, delete button really mean delete (to a recycle bin that’s purged in 30 days), not archive to a folder.

Also because Gmail is smart enough to save a copy in your [Gmail]/Sent Mail folder if you use their SMTP (out-going mail) server, the “Save copy of sent message in ‘Sent Items’ folder” setting on Windows Live Mail is irrelevant: you cannot choose not to save it.

And yes, I tried it checking this (for other non-Gmail accounts), and confirmed that Gmail is smart enough to save one copy (not one from the SMTP and one executed by the client).

So here’s a summary:

• Gmail automatically configures and dictates IMAP’s special folders. You have no choice
• No special folder choice means you cannot reroute ‘delete’ to mean archive/move
• If you use Gmail’s SMTP server (likely), it will save a copy of outgoing mail to [Gmail]/Sent Mail folder. You cannot turn this off.
• “Save copy of sent message in the ‘Sent Items’ folder‘ is irrelevant if you use Gmail’s SMTP server. It will correctly save only one copy of the sent mail.

 65 total views

Namecheap provides a free Dynamic DNS client for Windows but unfortunately the client cannot be run as a service. To manage remote computers, the dynamic DNS update should at least run before any user is logged or we’ll run into a chick-and-egg problem: you want to log in remotely but the IP of the remote computer is not known (mapped/updated) until you logged in.

I initially tried to use sc.exe to create a Windows service but the program lacks a ServiceMain() implementation so the service won’t start:

Turns out there is a way to wrap a Windows executable not designed to be used as a service (without ServiceMain() implementation) and make it run as a service. Use a tool called NSSM – the Non-Sucking Service Manager!

Note that the default setting for “Log on as” is “Local System Account”, which will not work with this free Namecheap Dynamic DNS client. You must set it to “Log on as” an Administrator account.

To start the newly created service without rebooting, do nssm start <servicename>, where <servicename> is replaced by the name you choose for the service.

Note that the ‘Path to executable’ for the newly created service is nssm.exe itself, not directly the DNS update client program (like what it’d be if you create the service through sc.exe instead of nssm.exe). The reason is that nssm.exe is the wrapper that calls the underlying executable.

 55 total views

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.

 118 total views