Service launcher and registry path

[Tomas Dalebjörk]

Hi

Is this link up to date?

https://github.com/winfsp/winfsp/wiki/WinFsp-Service-Architecture

According to AI it says the registry PATH instructions is pointing to some else location on 64bit OS.

I am trying to replace ny service code that no longer works on newer Windows version with the WinFsp launcher startup function.

But its a bit misleading, eg the launcher has <class> <instance> as mandatory argument.

But the registry only describe <class>?

How does this <instance> gets automatically mounted? Is this a sub register where one set the DWORD JobControl value to 1, and where is the arguments set in registry?

...

Yes — that page you quoted exists and indeed says this:

Please note that in a 64-bit system the actual location is HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\WinFsp\Services. 

GitHub

That is accurate historically (and still true for *some parts of WinFsp’s internal registry usage), but your interpretation of what that means in practice has to be clarified in light of how the WinFsp launcher actually reads the registry on a 64-bit system.

Here’s the precise, up-to-date distinction:

🧠 Two Registry Perspectives

1️⃣ What the WinFsp wiki documents

The wiki is referring to how registry keys are physically stored for the WinFsp service architecture on a 64-bit machine. On 64-bit Windows:

HKLM\SOFTWARE ← 64-bit view

HKLM\SOFTWARE\Wow6432Node ← 32-bit view

The quote:

“on a 64-bit system the actual location is HKLM\SOFTWARE\WOW6432Node\WinFsp\Services” 

GitHub

means:

The samples they showed (e.g., memfs32/memfs64) put their service registration in the 32-bit registry view.

This was written in a time where WinFsp was not fully consistent in its deployment.

But that documentation is old/outdated and does not reflect how the current WinFsp launcher implementation actually looks up registration keys.

2️⃣ How WinFsp actually works in practice today

In current versions of WinFsp (especially when using the launcher API like launchctl-x64.exe):

The WinFsp launcher is a 64-bit service.

It uses 64-bit registry access to read configuration.

It does not transparently merge or redirect the Wow6432Node keys when reading the filesystem service configuration.

This means for launcher-based filesystems:

HKLM\SOFTWARE\WinFsp\Services\… ← actual place launcher will read

Not:

HKLM\SOFTWARE\WOW6432Node\WinFsp\Services\…

Even though the wiki text may suggest the latter, the actual API behavior on modern 64-bit Windows is as if the values must appear in the 64-bit hive.

🧩 How WinFsp Samples Handled It

The historical sample in the wiki stores two keys:

HKLM\SOFTWARE\WOW6432Node\WinFsp\Services\memfs32

HKLM\SOFTWARE\WOW6432Node\WinFsp\Services\memfs64

That was done explicitly so that the 32-bit and 64-bit launcher tools created separate registry entries for each architecture. But notice:

The path shown in the wiki includes Wow6432Node intentionally.

It does not rely on automatic Wow6432Node redirection — it is writing to that path on purpose.

In other words, it anticipates the need to handle both architectures, and explicitly places 64-bit (memfs64) and 32-bit (memfs32) values under the Wow6432Node.

That scheme only works because later code in those samples is written to explicitly open Wow6432Node for both 32- and 64-bit launchers.

The modern launcher does not do that automatically. If you want cross-architecture keys, your code needs to create them both.

This is why, in practice:

A pure 64-bit filesystem works best if its registry keys are in the 64-bit view.

A 32-bit tool writing only to Wow6432Node does not suffice for a 64-bit launcher.

This is why, in practice:

A pure 64-bit filesystem works best if its registry keys are in the 64-bit view.

A 32-bit tool writing only to Wow6432Node does not suffice for a 64-bit launcher.

📌 Practical takeaway (no confusion)

Where it might be on disk Where the launcher reads

HKLM\SOFTWARE\Wow6432Node\WinFsp\Services ❌ Not looked at by 64-bit launcher unless you expressly open it with WOW64 flags

HKLM\SOFTWARE\WinFsp\Services ✅ Launcher reads this by default

So when the wiki says

use Wow6432Node on 64-bit,

it is describing how samples historically put keys there, NOT how the current launcher reads configuration.

Because of registry redirection rules on 64-bit Windows, a 32-bit writer might have ended up there automatically, but WinFsp launcher does not automatically mirror or merge Wow6432Node into the 64-bit view for service lookup.

This behavior is fully consistent with Windows registry semantics and common practice.

🧠 Summary – how to handle it correctly

To make your WinFsp filesystem work with launchctl:

If your launcher is 64-bit

Put your keys under:

HKLM\SOFTWARE\WinFsp\Services\<YourClass>

If you have separate 32- and 64-bit binaries

You may need both:

HKLM\SOFTWARE\WinFsp\Services\<class64>

HKLM\SOFTWARE\Wow6432Node\WinFsp\Services\<class32>

…and each “Executable” registry entry must point to the appropriate binary.

Final authoritative citation

The WinFsp wiki explicitly notes that examples put keys under Wow6432Node on a 64-bit system. 

GitHub

This is a sample documentation quirk, not a guarantee the launcher reads that location for all architectures.

[Bill Zissimopoulos]

Hello, Tomas:

Yes, you can have your own Windows service that is also a WinFsp file system. As long as your service is registered and correctly uses the Service Manager APIs to interact with Windows it will work.

As a convenience, WinFsp provides an API for creating Windows services. This API consists of functions named FspService*. However you do NOT need to use this API to create your Windows service; you can just use the standard Service Manager API.

As an additional convenience WinFsp provides a built-in Windows service called the Launcher. The Launcher is used to manage WinFsp file systems and provides an easy way to start (mount) and stop (dismount) file systems. The Launcher is also used to support Windows Shell operations like "Map Network Drive" and "Disconnect Network Drive".

The document at https://github.com/winfsp/winfsp/wiki/WinFsp-Service-Architecture is indeed current and explains how to set up your file system for the Launcher. In a nutshell your file system can be just a console executable that accepts standard command-line parameters and can be stopped by CTRL-BREAK (practically most Windows console executables).

The WinFsp installation includes a Launcher registration for the MEMFS file system, which you can study in order to understand how to set things up for your own file system.

Bill

--
You received this message because you are subscribed to the Google Groups "WinFsp" group.
To unsubscribe from this group and stop receiving emails from it, send an email to winfsp+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/winfsp/CACrcyfJ%3D_DVzO2KoX5GQOBLTp1LJzO4P7Lqj3Tbq6xAjyhpvfA%40mail.gmail.com.

[Tomas Dalebjörk]

The issue is that Windows 2025/Windows 11 no longer accept any argument for the executable.

In older Windows, the service code gets the name of the service as an argument.

But in newer Windows they removed that.

One has to loop all services, get current process, to check if that matches the service in scope.

According to articles I found on internet, Microsoft claims that it is a security issues to have arguments telling which service is being called.

I was able to fix this now, but where not aware of this changes...

Regards Tomas