Skip to content

Conversation

SkybuckFlying
Copy link

@SkybuckFlying SkybuckFlying commented Aug 6, 2025

I've decided to upload the broken code, (To a seperate branch called: "original_repo_broken_ServiceHandleMissing")

As far as I can tell the broken code is not really that big of an issue.

To fix it, it would probably require storing the ServiceHandle into the object.

h_sv is created somewhere, can't remember clearly, maybe storing that in ServiceHandle member field could fix this code.

For now I ran out of steam trying to fix this.

But perhaps you will find this code interesting to see what it does... there are some other fixes in here too.. in create ram and such in case for whatever reason ram disk creation fails, I could imagine this might happen if out of memory or something...

…k detachment.

The RamService was observed to cause hangs during Windows 11 shutdown.
The hypothesized cause is a race condition with the Service Control Manager (SCM).
The `DetachRamDisk` function, called directly during `ServiceStop` and `ServiceShutdown` events,
can be a long-running operation.
The SCM imposes a strict timeout for services to respond to control signals.
If the service fails to respond promptly, the SCM forcibly terminates it.
This premature termination likely left the RAM disk in an unstable state,
causing the OS shutdown process to hang while waiting for a resource that was not cleanly released.

This commit refactors the service's shutdown logic to prevent this timeout and ensure a graceful exit:

- **Introduced `TShutdownThread`**:
A dedicated thread is now responsible for executing the `DetachRamDisk` function.

- **Asynchronous Shutdown**: On `ServiceStop` or `ServiceShutdown`,
instead of detaching the disk directly,
the service now creates and starts the `TShutdownThread`.
This allows the main service thread to remain responsive and acknowledge the SCM request immediately.

- **Graceful Wait**:
The main `ServiceExecute` loop, upon termination,
now safely waits for the `TShutdownThread` to complete its execution.
This guarantees that the RAM disk is fully detached and cleaned up before the service process exits.

- **State Management**:
The `FShutdownThread` handle is initialized to `nil` on service start to ensure clean state management.

This change ensures the service signals its compliance with the shutdown request in a timely manner
while allowing the potentially lengthy disk detachment process to complete safely in the background,
resolving the system hang.

- (Note: RamService.dpr assumes a .\bin folder exists for outputting the binary, if this bin folder
   does not exist, the build might fail, either user must create bin folder or adjust project settings and
   remove bin from project settings.)

- First initial improvement, however, the system could still hang during long operations.
  The solution would be to periodically inform the system the shutdown service is still busy.
  These improvements will be attempted in a next commit.
The RamDisk service could hang or be terminated prematurely by the Service Control Manager (SCM) during startup or shutdown.
This was because the service did not report its status while performing long-running operations like creating or removing the RAM disk.
The SCM would interpret this lack of communication as the service being unresponsive and would terminate it.

This commit addresses the issue by implementing proper status reporting in `SrvMain.pas`.
The `ServiceStart` and `ServiceStop` procedures now:
1.  Set a `WaitHint` of 60 seconds, providing a generous timeout for the operations.
2.  Periodically call `ReportStatus` with an incrementing `CheckPoint` value.

This ensures the SCM is kept informed of the service's progress (SERVICE_START_PENDING, SERVICE_STOP_PENDING) and
prevents it from incorrectly flagging the service as hung, thereby improving service stability and reliability.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant