database system was not properly shut down

I ran the recent installer from EnterpriseDB (postgresql-9.3.4-2-windows-x64.exe) on a freshly installed Windows Server 2012 Datacenter with recent patches.  Default install, nothing fancy, next-next-next-finish.  So there is now a service "postgresql-x64-9.3" with automatic startup running commandline "C:\Program Files\PostgreSQL\9.3\bin\pg_ctl.exe" runservice -N "postgresql-x64-9.3" -D "C:/Program Files/PostgreSQL/9.3/data" -w".

Everytime I restart the OS I see in pg_log that "database system was not properly shut down; automatic recovery in progress". Pg_log is not quite consistent every shutdown, for example:

2014-04-18 15:10:31 CEST LOG:  received fast shutdown request

2014-04-18 15:10:31 CEST LOG:  aborting any active transactions

2014-04-18 15:10:31 CEST LOG:  autovacuum launcher shutting down

2014-04-18 15:10:32 CEST ERROR:  canceling statement due to user request

or 

2014-04-18 14:36:57 CEST LOG:  received fast shutdown request

2014-04-18 14:36:57 CEST LOG:  aborting any active transactions

2014-04-18 14:36:57 CEST FATAL:  terminating connection due to administrator command

2014-04-18 14:36:58 CEST FATAL:  terminating connection due to administrator command

2014-04-18 14:36:58 CEST FATAL:  terminating connection due to administrator command

2014-04-18 14:36:58 CEST FATAL:  terminating connection due to administrator command

2014-04-18 14:36:58 CEST FATAL:  terminating connection due to administrator command

2014-04-18 14:36:58 CEST LOG:  autovacuum launcher shutting down

2014-04-18 14:36:58 CEST ERROR:  canceling statement due to user request

2014-04-18 14:36:58 CEST FATAL:  the database system is shutting down

...

2014-04-18 14:37:08 CEST FATAL:  the database system is shutting down

2014-04-18 14:37:08 CEST LOG:  CreateProcess call failed: A blocking operation was interrupted by a call to WSACancelBlockingCall.

(error code 19)

2014-04-18 14:37:08 CEST LOG:  could not fork new process for connection: A blocking operation was interrupted by a call to WSACancelBlockingCall.

...

2014-04-18 14:37:09 CEST LOG:  CreateProcess call failed: A blocking operation was interrupted by a call to WSACancelBlockingCall.

(error code 19)

2014-04-18 14:37:09 CEST LOG:  could not fork new process for connection: A blocking operation was interrupted by a call to WSACancelBlockingCall.

or

2014-04-17 17:46:12 CEST LOG:  received fast shutdown request

2014-04-17 17:46:12 CEST LOG:  aborting any active transactions

2014-04-17 17:46:12 CEST FATAL:  terminating connection due to administrator command

2014-04-17 17:46:12 CEST FATAL:  terminating connection due to administrator command

2014-04-17 17:46:12 CEST FATAL:  terminating connection due to administrator command

2014-04-17 17:46:12 CEST FATAL:  terminating connection due to administrator command

2014-04-17 17:46:12 CEST LOG:  autovacuum launcher shutting down

2014-04-17 17:46:12 CEST ERROR:  canceling statement due to user request

2014-04-17 17:46:14 CEST FATAL:  the database system is shutting down

...

2014-04-17 17:46:23 CEST FATAL:  the database system is shutting down

2014-04-17 17:46:23 CEST LOG:  server process (PID 1388) was terminated by exception 0xC0000189

2014-04-17 17:46:23 CEST HINT:  See C include file "ntstatus.h" for a description of the hexadecimal value.

2014-04-17 17:46:23 CEST LOG:  terminating any other active server processes

2014-04-17 17:46:23 CEST WARNING:  terminating connection because of crash of another server process

2014-04-17 17:46:23 CEST DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.

2014-04-17 17:46:23 CEST HINT:  In a moment you should be able to reconnect to the database and repeat your command.

2014-04-17 17:46:23 CEST LOG:  abnormal database system shutdown

The "exception 0xC0000189" I found means "A write operation was attempted to a volume after it was dismounted." but other than that I'm hitting dead-ends.

   

Any suggestions how to troubleshoot this?  While the autorecovery is always successful so far, I don't want to push my luck with a productive database.

Kind regards,