Bugzilla

:bobowen pinged me to double-check if this issue may affect `updater.exe`, because since the landing of bug 1950060 we have chromium code running in `updater.exe` as well. I was able to reproduce the `firefox.exe` issue (so I was using the correct Windows version), but updating with `updater.exe` worked just fine.

Looking closer at what's happening, `firefox.exe` imports `AttachConsole` to be able to perform a call to `mozilla::UseParentConsole` in the launcher process (`mozilla::LauncherMain`). In the faulty builds of `firefox.exe`, we are importing `AttachConsole` through `api-ms-win-core-console-l1-2-0.dll`, while in working builds we are importing it from `KERNEL32.dll` (as shown by `dumpbin /imports firefox.exe`).

It seems that the problem was caused by linking with `mincore.lib` because `mincore.lib` and `kernel32.lib` both provide `AttachConsole` but through a different DLL, and in the faulty builds the version provided by `mincore.lib` took precedence over the one from `kernel32.lib`.

`updater.exe` doesn't import `AttachConsole`, which seems to be the specific function that caused trouble here. However, we do use `mincore.lib` in our `Library("zucchini")`, and it could take precedence for other functions. Given the issue we ran into here, it feels like it would be wise to remove the dependency in `zucchini` even though we don't appear to have a problem right now.

:bobowen pinged me to double-check if this issue may affect `updater.exe`, because since the landing of bug 1950060 we have chromium code running in `updater.exe` as well. I was able to reproduce the `firefox.exe` issue (so I was using the correct Windows version), but updating with `updater.exe` worked just fine.

Looking closer at what's happening, `firefox.exe` imports `AttachConsole` to be able to perform a call to `mozilla::UseParentConsole` in the launcher process (`mozilla::LauncherMain`). In faulty builds of `firefox.exe`, we are importing `AttachConsole` through `api-ms-win-core-console-l1-2-0.dll`, while in working builds we are importing it from `KERNEL32.dll` (as shown by `dumpbin /imports firefox.exe`).

It seems that the problem was caused by linking with `mincore.lib` because `mincore.lib` and `kernel32.lib` both provide `AttachConsole` but through a different DLL, and in the faulty builds the version provided by `mincore.lib` took precedence over the one from `kernel32.lib`.

`updater.exe` doesn't import `AttachConsole`, which seems to be the specific function that caused trouble here. However, we do use `mincore.lib` in our `Library("zucchini")`, and it could take precedence for other functions. Given the issue we ran into here, it feels like it would be wise to remove the dependency in `zucchini` even though we don't appear to have a problem right now.

:bobowen pinged me to double-check if this issue may affect `updater.exe`, because since the landing of bug 1950060 we have chromium code running in `updater.exe` as well. I was able to reproduce the `firefox.exe` issue (so I was using the correct Windows version), but updating with `updater.exe` worked just fine.

Looking closer at what's happening, `firefox.exe` imports `AttachConsole` to be able to perform a call to `mozilla::UseParentConsole` in the launcher process (`mozilla::LauncherMain`). In faulty builds of `firefox.exe`, we are importing `AttachConsole` through `api-ms-win-core-console-l1-2-0.dll`, while in working builds we are importing it from `KERNEL32.dll` (as shown by `dumpbin /imports firefox.exe`).

It seems that the problem was caused by linking with `mincore.lib` because `mincore.lib` and `kernel32.lib` both provide `AttachConsole` but through a different DLL, and in the faulty builds the version provided by `mincore.lib` took precedence over the one from `kernel32.lib`.

`updater.exe` doesn't import `AttachConsole`, which seems to be the specific function that caused trouble here. However, we do use `mincore.lib` in our `Library("zucchini")`, and it could take precedence for other functions. Given the issue we ran into here, it feels like it would be wise to remove the dependency on `mincore.lib` in `zucchini` as well even though we don't appear to have a problem right now.

:bobowen pinged me to double-check if this issue may affect `updater.exe`, because since the landing of bug 1950060 we have chromium code running in `updater.exe` as well. I was able to reproduce the `firefox.exe` issue (so I was using the correct Windows version), but in the latest Nightlies updating with `updater.exe` worked just fine.

Looking closer at what's happening, `firefox.exe` imports `AttachConsole` to be able to perform a call to `mozilla::UseParentConsole` in the launcher process (`mozilla::LauncherMain`). In faulty builds of `firefox.exe`, we are importing `AttachConsole` through `api-ms-win-core-console-l1-2-0.dll`, while in working builds we are importing it from `KERNEL32.dll` (as shown by `dumpbin /imports firefox.exe`).

It seems that the problem was caused by linking with `mincore.lib` because `mincore.lib` and `kernel32.lib` both provide `AttachConsole` but through a different DLL, and in the faulty builds the version provided by `mincore.lib` took precedence over the one from `kernel32.lib`.

`updater.exe` doesn't import `AttachConsole`, which seems to be the specific function that caused trouble here. However, we do use `mincore.lib` in our `Library("zucchini")`, and it could take precedence for other functions. Given the issue we ran into here, it feels like it would be wise to remove the dependency on `mincore.lib` in `zucchini` as well even though we don't appear to have a problem right now.