[Bug]: Throws prepareError(error) when launching the browser

[kenneypVL]

Describe the bug
When running puppeteer with the browser-with-fingerprints in a Windows Container in docker, the process will attempt to launch the browser and throw a prepareError as shown below after around 60s.

Note:
Running the process works when running locally in a Windows container with Docker but running the same container image on a Windows node in Kubernetes it gets the PrepareError().

browser-with-fingerprints\src\plugin\connector\index.js:55
        throw new Error(prepareError(error));
        Error: Timeout during creating new process

Steps to reproduce
Steps to reproduce the behavior:

1. Launch browser with puppeteer in a Windows Container

const browser = await plugin.launch({
  args: ['--mute-audio'],
  headless: true,
});

3. Wait around 60s
4. See error

Assumed Issue
I believe the issue is occurring because
In browser-with-fingerprints/src/plugin/connector/engine.js

• when the runFunction() gets called with name='setup'
  • startProcess() is called to launch FastExecuteScript.exe
  • await fs.writeFile(requestPath, JSON.stringify({ name, params })); is called to write the fingerprint to a json file
  • requestWatcher.on('change'... A listener is set to listen for changes to that json file
    However, I think FastExecuteScript.exe is never able to modify that file for some reason for the listener to pick up the change causing it to throw that prepareError().

Screenshots
In reference to the Assumed Issue section

Error:

System (please complete the following information):

• Plugin version: v2.0.4 (puppeteer-with-fingerprints)
• Node version: v21.6.1
• Chrome version: 131.0.6778.86
• Windows Container resources
  • 2 CPUs
  • 8 GB memory
• Using dotnet runtimes
  • Microsoft.AspNetCore.App 8.0.11
  • Microsoft.NETCore.App 8.0.11

[CheshireCaat]

Which OS version is used in the container?

[kenneypVL]

Which OS version is used in the container?

Windows Server 2022. I'm building the container using the image below along with the dotnet runtimes

[kenneypVL]

Hi, does bandwidth play a role in causing this issue? I asked because I am testing in the windows container while sharing my screen in an online call, it will always throw that error. However, once I'm not in a call anymore, the process will be successful. Does bandwidth play a role in running the FastExecuteScript.exe or in the process in general?