So, the problem is - when VDatabase.IsJournaled = False, the existing journal file prevents to open the db? Is there an error or something?

I'm not sure, but eestarting the computer must wait until all services are finished. Most probably it waits for some fixed time, and if the service does not finish just kills it.
Most probably there is some registry/environment key to change that time.

When VDatabase.IsJournaled = False, I can open the database, but it's not journaled anymore (and thus the journal file is not updated) despite the fact this file is "in use" by server as I cannot delete it if Server is not stopped.
Yes, vserver service seems to be killed. Perhaps it's the problem. I can see this behaviour with many computers now and it's very annoying. I would be nice to know how I can change that time...

I'm lost a bit - do you use VDatabase.IsJournaled = False intentionally or it is just a way to open some db after the computer restart?
What happens without VDatabase.IsJournaled = False?
Why journal file must be updated if you set VDatabase.IsJournaled = False?

I use VDatabase.IsJournaled to test if the journal file is frozen or correctly used. I don't set VDatabase.IsJournaled to false. I just test (get) this property.
I felt the need to test it seeing (during users support) many database with its .journal file frozen many month ago.

Ok, get it.

Could you send me the db and the journal right after restart (probably you should set "manual start" for the service to get exactly the state after computer restart)?
Probably this helps for increase waiting for service stop - https://stackoverflow.com/questions/13454054/what-is-the-maximum-time-windows-service-wait-to-process-stop-request-and-how-to

Also, please look into Warning...log file (most probably in the vlog vserver's folder) - is there something like "Unable to create rollback journal ..."? It must be a description of the resaon there

Could you send me the db and the journal right after restart

Ok. Sent to your personal email address (db and log file).

FYI, setting "WaitToKillServiceTimeout" to 20 seconds doesn't change this behaviour. It seems the vserver service doesn't close properly but is killed.

setting "WaitToKillServiceTimeout" to 20 seconds doesn't change this behaviour

I mean : before this change, this parameter was set to 5 seconds. Now Windows wait 20 seconds before killing the opened services if any, but the service vServer doesn't closed properly during this bigger laps of time and is killed.

I would suggest setting VerbooseLevel to 3 (in the INI). Then, vServer will produce WarningLog with an explanation of what happened and why it was not able to reuse the existing journal file (after starting).

This is the WarningLog file produced after a computer restart, when I manually restart the vserver and open the database file :

*****************************************************************

This log contains warnings from Valentina engine.

This log is useful during development and debugging.

To disable it for RELEASE, just after Valentina.Init() do

Valentina.SqlQuery(  "SET PROPERTY WarningMode TO FALSE" );

*****************************************************************

20221024_125821 : ServicePage of the rollback journal is invalid.  : master.vdb.journal

20221024_125821 : ServicePage of the rollback journal is invalid.  : master.vdb.journal

20221024_125831 : Unable to create rollback journal  : data.vdb.journal. Error: 365832 File "UNKNOWN" - is read only.

In order to be able to delete the file data.vdb.journal, if vserver is running, I must first manually stop the vserver service. Simply unregister the database doesn't "free" the data.vdb.journal file. I tried to
1. Unregister the database
2. Restart vserver service via API
3. delete data.vdb.journal file => error : the file is in use

Why journal file is read only is a mystery for me.
FYI, As seen in Services pane, vserver is logged on Local System user.

"Unregister the database" does not help anyway - it is for further clients - they will not be able to use the db, but internally db stays open until vServer stops. After vServer starts again, the db might be open either by the first client request (like it's db.Open call) or by vServer itself if "earlyOpenDb" in the INI is set to true or by vServer scheduler if there is some active event for that db.

Anyway, there is no sense to investigate why journal file is in such a state, because it seems vServer was killed in the middle of journal modification (in most cases it means that no real data changes were applied to the db, and so, db is healthy but lost the last changes). But there is always a chance to get damaged db, so it is not simply a question of how to force to drop such a journal and start over again.

The initial reason is - vServer shutdown takes more time than Windows allows for service to be stopped on its own. There is one more possibility - vServer crashed during shutdown - check Syslog, please.
So we should find out a way to increase that timeout.

You may try to stop it manually - just to be sure how long it takes. Also - please try to run it as a regular app - not a service, and manually stop it (The Cntrl-C signal is handled by vServer, so it is a valid way to stop it).

Probably the storage was dismounted or something before vServer gets a chance to quit?
Some OS/hardware upgrade? Any hint - after what this problem appears?

"Unregister the database" does not help anyway - it is for further clients - they will not be able to use the db, but internally db stays open until vServer stops.

"stays open" ?? However, as I can see, when I unregister the db, the journal file is deleted (Of course before unregister, I disconnect all connected client).

vServer shutdown takes more time than Windows allows for service to be stopped on its own.

As said earlier, increasing the timeout from 5 seconds to 20 seconds doesn't change anything.

There is one more possibility - vServer crashed during shutdown - check Syslog, please.

How can I do that ?

You may try to stop it manually - just to be sure how long it takes. Also - please try to run it as a regular app - not a service, and manually stop it (The Cntrl-C signal is handled by vServer, so it is a valid way to stop it).

Will try that.

Probably the storage was dismounted or something before vServer gets a chance to quit?
Some OS/hardware upgrade? Any hint - after what this problem appears?

Not that I know, unfortunately. I will investigate.

Can you explain how I can check Syslog, please ?

How can I do that ?

It's a first link from Google search:
https://www.partitionwizard.com/partitionmagic/windows-10-crash-log.html

"stays open" ?? However, as I can see, when I unregister the db, the journal file is deleted (Of course before unregister, I disconnect all connected client).

I meant a most common case. Yes, in some cases unregister db will lead to closing db by vServer.

As said earlier, increasing the timeout from 5 seconds to 20 seconds doesn't change anything.

But we don't know how much time actually it takes. Probably 20 sec is not enough as well.