Error 0xC004F074 despite successful connection to server

[dstagger]

I'm hosting py-kms in docker on diet pi. There are no network issues, IP and port are reachable. container also has the same timezone as the machine being activated.
Reopening this issue

Originally posted by @dstagger in #105 (comment)

[didotb]

have you tried grabbing the py-kms client and test your server's reply?

[didotb]

Please perform the initial debugging yourself and show us your methods and results. We need to be able to replicate your problem, if we can't replicate it, then we can't help you fix your problem.

Show us the full docker configuration you came up with, your logs that you've gathered during debugging, network layout, is anything inside a vm, is the docker engine inside WSL, etc.

[dstagger]

Please perform the initial debugging yourself

Please tell me more, like what? Which logs should I share and where do I get them?

This is how the docker container is being started in a DietPi VM running in proxmox on a separate machine.

docker run -d --name py-kms --restart always -p 1688:1688 -e TZ=Europe/Amsterdam -v /etc/localtime:/etc/localtime:ro ghcr.io/py-kms-organization/py-kms

The IP and port are reacheable from the client machine:

PS> Test-NetConnection -ComputerName 192.168.x.x -Port 1688

ComputerName     : 192.168.x.x
RemoteAddress    : 192.168.x.x
RemotePort       : 1688
InterfaceAlias   : Home
SourceAddress    : 192.168.x.y
TcpTestSucceeded : True

[xf22cn]

You used two parameters simultaneously to use local time.
It is not recommended to use it this way.
You can use the following command to use local time:

Using the - e parameter
docker run -d --name py-kms --restart always -p 1688:1688 -e TZ=Europe/Amsterdam ghcr.io/py-kms-organization/py-kms

Alternatively, use the - v parameter
docker run -d --name py-kms --restart always -p 1688:1688 -v /etc/localtime:/etc/localtime:ro ghcr.io/py-kms-organization/py-kms

It is recommended to prioritize using the - e parameter command.
On some servers, the - v parameter will cause the Docker container to fail to start.

[xf22cn]

If the above suggestions still cannot solve your problem, please post the Docker log.
The command is as follows:

docker logs py-kms

If there is no output, it indicates that the py-kms container has not started.
In this case, please delete the py-kms container and use the correct command to rebuild:

docker run -d --name py-kms --restart always -p 1688:1688 -e TZ=Europe/Amsterdam ghcr.io/py-kms-organization/py-kms

[dstagger]

Yes, I added the -e parameter as the -v parameter wasn't working (as in setting the time)
Now I dropped the -v and started with -e as you've mentioned above. It takes ~4 mins to start. Is the normal?

CONTAINER ID   IMAGE                                          COMMAND                  CREATED         STATUS                            PORTS                                       NAMES
b2818c258561   ghcr.io/py-kms-organization/py-kms             "/usr/bin/python3 -u…"   3 minutes ago   Up 3 minutes (health: starting)   0.0.0.0:1688->1688/tcp, :::1688->1688/tcp   py-kms

I don't see anything on the py-kms logs when I call slmgr.vbs /ato on the client machine, which explains why I'm getting the error.
But the port is open and reachable as mentioned above. I also successfully get a response from the server when I test with pykms_Client.py from the client machine, which I'm trying to acivate:

PS C:\Users\xxx\py-kms-master\py-kms> py .\pykms_Client.py 192.168.x.y 1688
C:\Users\xxx\py-kms-master\py-kms\pykms_Client.py:173: SyntaxWarning: invalid escape sequence '\('
  name = re.sub('\(.*\)', '', kmsitem['DisplayName']) # Remove bracets

                        Client generating RPC Bind Request...

Server receiving
<===============        Client sending RPC Bind Request...

Server sending
===============>        Client received RPC Bind Response !!!

                        RPC Bind acknowledged !!!

C:\Users\xxx\py-kms-master\py-kms\pykms_Client.py:331: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
  requestDict['requestTime'] = dt_to_filetime(datetime.datetime.utcnow())
                        Client generating Activation Request dictionary...

                        Client generating Activation Request data...

                        Client generating RPC Activation Request...

Server receiving
<===============        Client sending RPC Activation Request...

Server sending
===============>        Client received Response !!!

                        Activation Done !!!

And of course, I can also see corresponding logs in the py-kms docker KMS server instance for this activation request.

Mon, 10 Jun 2024 10:29:10 INFO     Connection accepted: ::ffff:192.168.x.z:49188
Mon, 10 Jun 2024 10:29:10 INFO     RPC bind request received.
Mon, 10 Jun 2024 10:29:10 INFO     RPC bind acknowledged.
Mon, 10 Jun 2024 10:29:10 INFO     Received activation request.
Mon, 10 Jun 2024 10:29:10 INFO     Received V6 request on Mon Jun 10 10:29:10 2024.
Mon, 10 Jun 2024 10:29:10 WARNING  Module 'tzlocal' or 'pytz' not available ! Request time not localized.
Mon, 10 Jun 2024 10:29:10 WARNING  With count = 26, activated client could be detected as not genuine !
Mon, 10 Jun 2024 10:29:10 INFO     Machine Name: ffZeGhevyOxlD6Qj41Uwx5Zw1k3jlzmN
Mon, 10 Jun 2024 10:29:10 INFO     Client Machine ID: 72011e8d-654d-45aa-ba2a-695f4a638bea
Mon, 10 Jun 2024 10:29:10 INFO     Application ID: Windows
Mon, 10 Jun 2024 10:29:10 INFO     SKU ID: Windows 8.1 Enterprise
Mon, 10 Jun 2024 10:29:10 INFO     License Status: Grace Period
Mon, 10 Jun 2024 10:29:10 INFO     Request Time: 2024-06-10 08:29:09  (UTC)
Mon, 10 Jun 2024 10:29:10 INFO     Server ePID: 03612-00206-561-004470-03-1033-17763.0000-2372023
Mon, 10 Jun 2024 10:29:10 INFO     KMS V6 Response: 

                                   ResponseV5
                                   bodyLength1: {260}
                                   bodyLength2: {260}
                                   versionMinor: {0}
                                   versionMajor: {6}
                                   salt: {b"q_\xae?})Fp%#LF\x00'\x88+"}
                                   encrypted: {b'\x13\x94O\xfc=Dh\xb9\x9b\xdb\xe2%\n\xd7u\x03,^~2\xda\xab\x829\x99\x80N\x17\xdf\x022l\x
                                   d2$M\x06-\xd8\xad\xaccu~\x0b-\xd7\xc7\x13\x9bB+\xae\x903\xb9\xdd\x14\x0e\xdb"\xe7\xafj\x1a{jj\x93\xf
                                   7\xb0L\x00\xd1s:\xeb\xaa\xc2\x90Xdep\xc82|:C\xe7\x14\xd8\xe5(_\x9d\xad\x06\xf4\x1e\xb6\x13m\x95\x18_
                                   -F\xbbj\x15\xedq\xf9\xf2\x11\x0c\xa279\xec\xb5\xb7\xccfk\x7f\xd9G\x9cQ\xc2\xf7\x1d^\xa6e~\xcd\xd5\x9
                                   1\xd6\x02\\\x0c\xab\xa3\xc2\xf2\x97\x92u\xb7\xa78\xb0;\xf4\x80*\x8e^\x8e\xd9\xb8~\xef4\x9c\x0e\xa14\
                                   x9c\x07=\xce\xd1\xafI\x0e\xda\x94\x9a\xb3\x9bB\xef\xfe\xd51\xac,\xb5\xe7\xbe\xd2\xf8\xd57\x9dA\xd2\x
                                   8a\xf6\xbc\xca\x1bW\x86j\x96\xd7\xe7\xf6<\xd8!\xb4uU/\xf4\xf5\xca\x01\xaa.`!f\xc08z\xb5Q\xf6\xfe\xb9
                                   %\x94\xe4'}
                                   padding: {b'\x00\x00\x00\x00'}

Mon, 10 Jun 2024 10:29:10 INFO     KMS V6 Structure Bytes: 

                                   04010000000002000401000000000600715fae3f7d29467025234c460027882b13944ffc3d4468b99bdbe2250ad775032c5e
                                   7e32daab823999804e17df02326cd2244d062dd8adac63757e0b2dd7c7139b422bae9033b9dd140edb22e7af6a1a7b6a6a93
                                   f7b04c00d1733aebaac29058646570c8327c3a43e714d8e5285f9dad06f41eb6136d95185f2d46bb6a15ed71f9f2110ca237
                                   39ecb5b7cc666b7fd9479c51c2f71d5ea6657ecdd591d6025c0caba3c2f2979275b7a738b03bf4802a8e5e8ed9b87eef349c
                                   0ea1349c073dced1af490eda949ab39b42effed531ac2cb5e7bed2f8d5379d41d28af6bcca1b57866a96d7e7f63cd821b475
                                   552ff4f5ca01aa2e602166c0387ab551f6feb92594e400000000

Mon, 10 Jun 2024 10:29:10 INFO     Responded to activation request.
Mon, 10 Jun 2024 10:29:10 INFO     Connection closed: ::ffff:192.168.x.z:49188

[didotb]

It takes ~4 mins to start. Is the normal?

It should still be building some stuff you can wait for it to say it's healthy, mine took 2 hours, but it should still be able to issue activation while it's starting.

I just made another server, this time on an Ubuntu Server 22.04 LTS within Hyper-V with external network access.
I was able to activate multiple windows editions using your docker run command during both starting and healthy statuses.
(i.e. I did a v4 and v6 activation for sanity check just 3 minutes in during starting status, and did another set around 2 hours in during healthy status; and both sets completed without problems.)

I have no idea why you can't activate your windows device when you can ping it. A read on the official troubleshooting might help?
All I could think of right now is to wait for an amount of time without putting the container down, and re-doing the activation.

Since you're already on proxmox, why not try an ubuntu server or debian instead of dietpi?
I highly doubt things would change, but as a sanity check, it'd be a good test.

[dstagger]

A read on the official troubleshooting might help?

Yeah, already went through it. Nothing on event logs, even the call to the kms server isn't being made, it seems like. I think I need to dig deeper with wireshark etc.