ModuleNotFoundError: No module named 'winrt.windows.foundation.collections'

[SilverKnightVGM]

To Reproduce
Steps to reproduce the behaviour:

1. Download and run application as stated in the readme, using the Windows binaries and instructions provided (https://github.com/builder555/PineSAM?tab=readme-ov-file#i-easy-method).

Expected behaviour
The server pairs with the Pinecil V2 without errors and can be controlled with the web frontend.

Actual behaviour
The server never pairs with the PInecil and the frontend can't be used, even though it shows up just fine. The console shows the following error over and over:

19:21:32.473::INFO::Starting pinecil monitor
19:21:32.473::INFO::waiting for pinecil...
19:21:32.474::INFO::Detecting "pinecil"...
19:21:32.514::INFO::server listening on 0.0.0.0:12999
19:21:33.754::ERROR::Exception in callback BleakScannerWinRT._received_handler(<winrt._winrt...002B3A635B890>, <winrt._winrt...002B3A643CC70>)
handle: <Handle BleakScannerWinRT._received_handler(<winrt._winrt...002B3A635B890>, <winrt._winrt...002B3A643CC70>)>
Traceback (most recent call last):
  File "asyncio\events.py", line 84, in _run
  File "bleak\backends\winrt\scanner.py", line 139, in _received_handler
ModuleNotFoundError: No module named 'winrt.windows.foundation.collections'

Specs:

• OS: Windows 10
• Browser: Chrome
• PineSAM Version: v1.14.3 (also tried with v1.14.2)
• IronOS build/date: 2.22.E.C308FE8C, 05-11-23

Additional context
Tried (and failed) to run on two separate Windows 10 laptops. I did also later try to pair the Pinecil manually to the PC via Bluetooth, and it paired just fine.

[brookst]

I just had the same issue. Checking out the code and running a dev build works fine, but I think I installed winrt.windows.foundation.collections before testing. Even with it uninstalled I can't reproduce on the dev copy but it might be lingering in Windows somehow.

I suspect that the github build config needs to install this package prior to building the pyinstaller executables. E.g. add winrt-Windows.Foundation.Collections to the end of this:

PineSAM/.github/workflows/build.yml

Line 115 in 4817ef3

pip install pyinstaller websockets bleak requests

Then a build would have to be triggered and the artefacts checked to see if the module gets baked in. I haven't messed around with github workflows recently so I don't know how to test that easily.

[brookst]

After much messing around, I think the problem lies on the builder hosts: https://github.com/builder555/PineSAM/actions/runs/6960669786/job/18940658644#step:6:78

7144 WARNING: Library not found: could not resolve 'api-ms-win-core-path-l1-1-0.dll', dependency of 'C:\\hostedtoolcache\\windows\\Python\\3.12.0\\x64\\python312.dll'.
27144 WARNING: Library not found: could not resolve 'api-ms-win-core-libraryloader-l1-2-0.dll', dependency of 'C:\\hostedtoolcache\\windows\\Python\\3.12.0\\x64\\Lib\\site-packages\\winrt\\_winrt_windows_devices_bluetooth_advertisement.cp312-win_amd64.pyd'.
27144 WARNING: Library not found: could not resolve 'api-ms-win-core-libraryloader-l1-2-0.dll', dependency of 'C:\\hostedtoolcache\\windows\\Python\\3.12.0\\x64\\Lib\\site-packages\\winrt\\_winrt_windows_storage_streams.cp312-win_amd64.pyd'.
27144 WARNING: Library not found: could not resolve 'api-ms-win-core-libraryloader-l1-2-0.dll', dependency of 'C:\\hostedtoolcache\\windows\\Python\\3.12.0\\x64\\Lib\\site-packages\\winrt\\_winrt_windows_foundation.cp312-win_amd64.pyd'.
27144 WARNING: Library not found: could not resolve 'api-ms-win-core-libraryloader-l1-2-0.dll', dependency of 'C:\\hostedtoolcache\\windows\\Python\\3.12.0\\x64\\Lib\\site-packages\\winrt\\_winrt_windows_devices_enumeration.cp312-win_amd64.pyd'.
27144 WARNING: Library not found: could not resolve 'api-ms-win-core-libraryloader-l1-2-0.dll', dependency of 'C:\\hostedtoolcache\\windows\\Python\\3.12.0\\x64\\Lib\\site-packages\\winrt\\_winrt_windows_devices_bluetooth_genericattributeprofile.cp312-win_amd64.pyd'.
27144 WARNING: Library not found: could not resolve 'api-ms-win-core-libraryloader-l1-2-0.dll', dependency of 'C:\\hostedtoolcache\\windows\\Python\\3.12.0\\x64\\Lib\\site-packages\\winrt\\_winrt_windows_devices_bluetooth.cp312-win_amd64.pyd'.
27144 WARNING: Library not found: could not resolve 'api-ms-win-core-libraryloader-l1-2-0.dll', dependency of 'C:\\hostedtoolcache\\windows\\Python\\3.12.0\\x64\\Lib\\site-packages\\winrt\\_winrt.cp312-win_amd64.pyd'.

There's some potential solutions to the problem here: https://stackoverflow.com/questions/48712154/pyinstaller-warning-lib-not-found

I'll try these out on my fork at some point.

I also ran into this issue while building locally: pyinstaller/pyinstaller#8075
I got this working by checking the path for the _internal directory. The patch needs squashing and cherry-picking out of my test commits.

[IngmarG]

Also tried just about everything.
Same error.
Python 3.12

[builder555]

if you can create a PR, that'd be great, i don't have easy access to a windows machine and testing in gh actions is extremely slow in my experience.

[brookst]

testing in gh actions is extremely slow

Too right. I gave it a go on my GitHub fork but I'm at a bit of a loss on how to get this working properly.

I think the issue must be some kind of caching issue with GH actions. The workers seem to have the WinRT python DLLs (in C:\hostedtoolcache\ etc.) compiled against api-ms-win-core-libraryloader-l1-2-0.dll and api-ms-win-core-path-l1-1-0.dll. But the DLLs they have (in C:\Windows\System32\downlevel) are api-ms-win-core-libraryloader-l1-1-0.dll, api-ms-win-core-libraryloader-l1-1-1.dll and seem to be missing any api-ms-win-core-path* entirely. This is identical to my machine. So I don't know where these pyds have come from.

I've just opened an issue on the winrt-api tracker. Hopefully there's a simple way to make this work correctly.

I'll wait on a response there to see if we can get this built correctly before checking if the version.txt path issue really needs fixing.

[builder555]

@SilverKnightVGM I got a hold of a windows VM so I was able to test some stuff, I also redesigned quite a bit of architecture. Give it a try: https://github.com/builder555/PineSAM/releases/tag/v2.1.14

[brookst]

So this does work, but there are a few hoops to go through:

First, Windows defender picks up the exe as an instance of Trojan:Win32/Wacatac.B!ml
I don't see how that can be given it's built on Microsoft's servers. I think there's a lot of false positives with this detection type. I've submitted it to them here: https://www.microsoft.com/en-us/wdsi/submission/e1aa31b0-5c8e-43c9-a84b-995416eca1b3
In the meantime I've allowed the threat in Windows Security.

Second, the start.ps1 script also isn't signed, so I have to start it with powershell -ExecutionPolicy Bypass -File .\start.ps1. Executing from file explorer raises the same error, unless approved on the Security Warning dialog box with the "Always ask before opening this file" checkbox unchecked. I'm not sure if there's a better option there.

Third, I can only get this to work using the hostname for the URL. 'localhost' and 127.0.0.1 don't seem to work, I just get a connection reset message in the browser with no corresponding log output.
If I modify the start.ps1 file line 8 to read Start-Process "http://${env:COMPUTERNAME}:8080/", then it seems to work ok.
In Process Explorer, pinecil.exe seems to have bound :8080, host.docker.internal:8080 (which also works), kubernetes.docker.internal:62144 and kubernetes.docker.internal:62145. I don't have kubernetes installed, but I do have docker running with WSL. This might be a weird interaction with WSL but I don't understand what on earth it's doing.

In any case, the ModuleNotFoundError has gone away, so that's progress. I wonder if the GH actions caches have changed or if the build runs differently now due to configuration changes. The two issues I opened with the winrt-api got assignees two weeks ago, but no comments as of yet. winrt-api#2440 is the most relevant.

[builder555]

I saw that Trojan alert as well, I thought it was just some glitch on my machine. I mean you can try building it locally using ci/build.ps1 should get the same result. Thanks for the link, I'll submit my report there as well.

I'll look into adding self-signed certificate for the script, not sure if it'll help with the policy issue. I had to do Unblock-File start.ps1 before being able to run the script. I'll see which way is the easiest and update the documentation accordingly.

As for url, I just tried in edge, brave, and firefox, all worked with http://localhost:8080 and http://127.0.0.1:8080. Which browser are you using?
Also, are you running it from WSL or directly in powershell? I ran mine in powershell.
What happens if you run Pinesam.exe directly (and then navigate to http://localhost:8080)?

I updated the build script with --hidden-import=winrt.windows.foundation.collections that seems to have addressed that winrt issue.

UPDATE: I looked into it, self-signed certificates are basically useless - the same error will pop up. But on a fresh windows 10 installation latest release (v2.1.15) of Pinesam.exe started without issues (running it directly). The only downside is it doesn't automatically open a browser window.

[builder555]

@brookst I got a reply from Microsoft, seems like they added pinesam to their exceptions and what not, so the trojan error should disappear. With that the urls now should work. So let me know if running Pinesam.exe directly and opening localhost:8080 manually is a feasible strategy.

[brookst]

Ah good. My submission came back as "We cannot reproduce any detection on the file." I added an exception to Windows defender to test it, so I'm not sure if I can now check that it passes.

I can't seem to reproduce the hostname issue. It looks like Process Explorer was resolving hostnames so even if it was bound to 0.0.0.0 as expected, it would be reported as the system hostname. That doesn't explain why nothing would actually connect on localhost and 127.0.0.1. The problem came and went a few times without me figuring out a pattern so I don't think I can track it down.

If the problem re-occurs I'll look into it and open another issue, but things seem to be working ok for now. The only remaining annoyance is having to allow the shellscript to run. I wonder if the binary could launch the browser itself, since that's the only real purpose of the script. Maybe a flag could skip that if users don't want that behaviour.

[builder555]

Yeah,I'm sure it can be done from inside python. I'll dig into ti

[brookst]

Ah, I also meant to point out that the logs still show the error, but it doesn't occur on my system anymore.

See line 87 in the build step here: https://github.com/builder555/PineSAM/actions/runs/7686744109/job/20945954171#step:6:88

I'm also not sure what to make of that.

[builder555]

Ah, I also meant to point out that the logs still show the error, but it doesn't occur on my system anymore.

See line 87 in the build step here: https://github.com/builder555/PineSAM/actions/runs/7686744109/job/20945954171#step:6:88

I'm also not sure what to make of that.

no idea, i'm really not a specialist in windows. from a brief search, the suggestion is basically to find that dll and copy it manually.
but if the binary works, i say ignore it.