The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 2,481 other followers

Archive for the ‘Windows Development’ Category

Zombie Processes are Eating your Memory | Random ASCII

Posted by jpluimers on 2021/10/21

Zombies probably won’t consume 32 GB of your memory like they did to me, but zombie processes do exist, and I can help you find them and make sure that developers fix them…

Source: [WayBackZombie Processes are Eating your Memory | Random ASCII

For my link archive via [WayBack] In short, close handles after process opening or creation, or it leaks and zombie process stays consuming 64k. – Ilya S – Google+


Posted in Development, Software Development, Windows Development | Leave a Comment »

Some Windows 10 updates remove registry values; not sure how widely

Posted by jpluimers on 2021/10/12

After watching an autologon system not logging on automatically over the past years, the pattern seems to be that at least major, and some less minor Windows updates remove autlogon parts of the registry.

I’m not sure where the boundary between “major” and “less minor” lies (though I suspect “cumulative updates” and larger), nor if more than these values are affected:

  • key "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
    • value name AutoAdminLogon gets removed or becomes value 0
    • value DefaultUserName gets removed
    • value DefaultPassword gets removed

This means that now after each startup, I need to schedule a task that runs a script setting the values I need depending if a password is needed or not.

The script also needs credentials, so I need to figure out how to properly do that.

I still need to decide between PowerShell or batch file script, as I already have the batch file from How to turn on automatic logon in Windows and automatic logon in Windows 2003.

For my future reference, some more links on things that can get deleted:

Hopefully these links will help me writing the scripts:


Posted in Batch-Files, CommandLine, Development, Power User, PowerShell, PowerShell, Scripting, Software Development, Windows, Windows 10, Windows Development | Leave a Comment »

Use the System File Checker tool to repair missing or corrupted system files

Posted by jpluimers on 2021/09/30

[WayBack] Use the System File Checker tool to repair missing or corrupted system files:

Read the rest of this entry »

Posted in Development, Power User, Software Development, Windows, Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Development | Leave a Comment »

Windows Sandbox: a feature I forgot about

Posted by jpluimers on 2021/09/29

The Windows Sandbox can be useful, but since it was never there in the first decades of my Windows usage, I forgot it was added.

I wonder how it is implemented, as it is really useful to test out new stuff, but I wonder what it protects against.

A few years back, I bumped into this because the [WayBack] Desktop Goose by samperson got viral (it can be downloaded from [WayBack/] Desktop Goose

via [] Samperson on Twitter: “I made a goose that destroys your computer Download it free here:” / Twitter

So here are some links (you need at least build 1903 ([WayBack] Windows 10 May 2019 or 19H1) or Insider Preview Build 18305):

You can install it even if your Windows machine itself is a VM. For a physical machine, hardware virtualisation needs to be enabled (usually in the BIOS); for a VM, nested virtualisation enabled (check that in your virtualisation environment: Hyper-V, ESXi and others vary slightly on how to enable this).

Installation inside the Windows machine can be done via PowerShell (or the UI):

Note that starting the SandBox from an x86 process might require you to run a different WindowsSandBox.exe; see [WayBack] Launching Wsb (Windows Sandbox Config file) gives error – Total Commander:

you can use C:\WINDOWS\Sysnative\WindowsSandbox.exe in stead of C:\WINDOWS\System32\WindowsSandbox.exe in TC 32bit.

Also see:
[WayBack] On 64-bit Windows versions, some files and folders shown by Windows Explorer are not shown by Total Commander!

[WayBack] Windows x64: Explorer vs TC: Content of System32 different


Read the rest of this entry »

Posted in Development, Power User, Software Development, Windows, Windows Development | Leave a Comment »

Unix and NTFS file systems, hardlinks, inodes, files, directories, dot directories, bugs and implementation details

Posted by jpluimers on 2021/09/21

Lots of interesting tidbits on unix and NTFS file systems.

If you want to blow up your tooling, try creating a recursive hardlink…, which is likely one of the reasons that nx file systems do not support them.

Covered and related topics:

The tweets (especially follow the train of thought in the various subtrees: a great way to learn new things!):

It is important to understand that the concept File IDs and inode/vnode has far reaching consequences, for instance from [WayBack] inode – Wikipedia

  • Files can have multiple names. If multiple names hard link to the same inode then the names are equivalent; i.e., the first to be created has no special status. This is unlike symbolic links, which depend on the original name, not the inode (number).
  • An inode may have no links. An unlinked file is removed from disk, and its resources are freed for reallocation but deletion must wait until all processes that have opened it finish accessing it. This includes executable files which are implicitly held open by the processes executing them.
  • It is typically not possible to map from an open file to the filename that was used to open it. The operating system immediately converts the filename to an inode number then discards the filename. This means that the getcwd() and getwd() library functions search the parent directory to find a file with an inode matching the working directory, then search that directory’s parent, and so on until reaching the root directorySVR4 and Linux systems maintain extra information to make this possible.
  • Historically, it was possible to hard link directories. This made the directory structure into an arbitrary directed graph contrary to a directed acyclic graph. It was even possible for a directory to be its own parent. Modern systems generally prohibit this confusing state, except that the parent of root is still defined as root. The most notable exception to this prohibition is found in Mac OS X (versions 10.5 and higher) which allows hard links of directories to be created by the superuser.[10]
  • A file’s inode number stays the same when it is moved to another directory on the same device, or when the disk is defragmented which may change its physical location. This also implies that completely conforming inode behavior is impossible to implement with many non-Unix file systems, such as FAT and its descendants, which don’t have a way of storing this invariance when both a file’s directory entry and its data are moved around.
  • Installation of new libraries is simple with inode file systems. A running process can access a library file while another process replaces that file, creating a new inode, and an all-new mapping will exist for the new file so that subsequent attempts to access the library get the new version. This facility eliminates the need to reboot to replace currently mapped libraries.
  • It is possible for a device to run out of inodes. When this happens, new files cannot be created on the device, even though there may be free space available. This is most common for use cases like mail servers which contain many small files. File systems (such as JFS or XFS) escape this limitation with extents or dynamic inode allocation, which can “grow” the file system or increase the number of inodes.

A very cool read in the midst of the tweet tree was this reference to former Google Plus by [WayBack] Rob Pike – Wikipedia (of Golang, Unix team and Plan 9 fame).

WayBack: A lesson in shortcuts.Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. … – Rob Pike – Google+

A lesson in shortcuts.

Long ago, as the design of the Unix file system was being worked out, the entries . and .. appeared, to make navigation easier. I’m not sure but I believe .. went in during the Version 2 rewrite, when the file system became hierarchical (it had a very different structure early on).  When one typed ls, however, these files appeared, so either Ken or Dennis added a simple test to the program. It was in assembler then, but the code in question was equivalent to something like this:
if (name[0] == ‘.’) continue;
This statement was a little shorter than what it should have been, which is
if (strcmp(name, “.”) == 0 || strcmp(name, “..”) == 0) continue;
but hey, it was easy.

Two things resulted.

First, a bad precedent was set. A lot of other lazy programmers introduced bugs by making the same simplification. Actual files beginning with periods are often skipped when they should be counted.

Second, and much worse, the idea of a “hidden” or “dot” file was created. As a consequence, more lazy programmers started dropping files into everyone’s home directory. I don’t have all that much stuff installed on the machine I’m using to type this, but my home directory has about a hundred dot files and I don’t even know what most of them are or whether they’re still needed. Every file name evaluation that goes through my home directory is slowed down by this accumulated sludge.

I’m pretty sure the concept of a hidden file was an unintended consequence. It was certainly a mistake.

How many bugs and wasted CPU cycles and instances of human frustration (not to mention bad design) have resulted from that one small shortcut about  40 years ago?

Keep that in mind next time you want to cut a corner in your code.

(For those who object that dot files serve a purpose, I don’t dispute that but counter that it’s the files that serve the purpose, not the convention for their names. They could just as easily be in $HOME/cfg or $HOME/lib, which is what we did in Plan 9, which had no dot files. Lessons can be learned.)


Read the rest of this entry »

Posted in *nix, Development, File-Systems, History, NTFS, Power User, Software Development, Windows, Windows Development | Leave a Comment »

%d bloggers like this: