← Signal Queue

How I fixed updated Steam in Whisky on macOS: SteamWebHelper crash, outdated Wine, CrossOver Wine 11, latest Steam client for steamFriend17

new

Post

macOS Whisky Steam SteamWebHelper Wine CrossOver CEF Apple Silicon Windows games on Mac steamFriend17 Project Doors: demo I’m posting this because I spent a lot of time trying to make the current Windows Steam client work inside Whisky on macOS. My goal was not just “launch a game somehow” or use old/headless Steam. I specifically needed the official, logged-in, updated Steam client with UI, because Project Doors Demo depends on steamFriend17 , and that version only exists in the current Steam client. In the end, I managed to update Steam to the latest client inside a Whisky bottle and get the Steam UI working again. The short version: Whisky itself was still usable as the bottle manager. The old Whisky Wine runtime was the real problem. I replaced Whisky’s Wine runtime with CrossOver’s newer Wine 11 runtime. I cleaned/reinstalled Steam while preserving steamapps , config , and userdata . Steam updated successfully to the current client. steamwebhelper stopped crashing and the Steam UI launched. My final Steam client version was: Client version / buildid: 1781041600 Updater built: Jun 9 2026 CEF folder used: cef.win64 Windows version inside bottle: Windows 10.0.19045 Wine version used by Whisky after the fix: wine-11.0-8723-g7e8a47752e3 Original problem Steam in Whisky was failing because the bundled Whisky Wine was too old for the current Steam UI stack. The symptoms were: steamwebhelper is not responding Steam UI is unavailable or Steam would crash/restart steamwebhelper repeatedly. In dumps/logs it looked like a CEF/Chromium problem inside Steam’s UI layer. The important part is that the problem was no longer “Steam cannot update” or “the bottle is Windows 8.1”. Steam had already updated far enough, but the new UI stack could not run correctly on the old Wine runtime. Important context Whisky’s bundled Wine was old. In my case it was basically WhiskyWine 7.x-era behavior. Modern Steam uses a Chromium/CEF-based UI through steamwebhelper.exe . The current Steam client needs a much newer Wine than old Whisky provides. So the fix was not to disable Steam UI, not to use -no-browser , not to use old Steam forever, and not to block updates. The fix was to make Whisky use a newer Wine runtime. What I used I installed CrossOver 26.2.0, which included a Wine 11 build. Path: /Applications/CrossOver.app/Contents/SharedSupport/CrossOver The Wine version I got from it: wine-11.0-8723-g7e8a47752e3 Bottle path My Whisky bottle was here: BOTTLE="$HOME/Library/Containers/com.isaacmarovitz.Whisky/Bottles/927CAB56-A21C-4FAB-9DB0-326FC26DE497" Your bottle UUID will be different. Steam was installed here: STEAMDIR="$BOTTLE/drive_c/Program Files (x86)/Steam" Step 1: Make sure the bottle is Windows 10 Steam must see Windows 10, not Windows 8.1. After the fix, this command reported: Microsoft Windows 10.0.19045 If your bottle is still pretending to be Windows 8.1, current Steam will refuse to work properly. Step 2: Install CrossOver I installed CrossOver 26.2.0. You can use the official CrossOver app. The important thing is that you need its newer Wine runtime. After installation, check that this exists: ls "/Applications/CrossOver.app/Contents/SharedSupport/CrossOver" Step 3: Replace Whisky’s Wine launcher with a wrapper to CrossOver Wine Whisky normally launches its bundled Wine from: "$HOME/Library/Application Support/com.isaacmarovitz.Whisky/Libraries/Wine/bin/wine64" "$HOME/Library/Application Support/com.isaacmarovitz.Whisky/Libraries/Wine/bin/wineserver" I backed those up first. Example: RUNTIME="$HOME/Library/Application Support/com.isaacmarovitz.Whisky/Libraries/Wine/bin" cp "$RUNTIME/wine64" "$RUNTIME/wine64.whiskywine-backup" cp "$RUNTIME/wineserver" "$RUNTIME/wineserver.whiskywine-backup" Then I replaced wine64 with this wrapper: #!/bin/sh set -eu CX_ROOT="/Applications/CrossOver.app/Contents/SharedSupport/CrossOver" REAL_WINE="$CX_ROOT/lib/wine/x86_64-unix/wine" export CX_ROOT export PATH="$CX_ROOT/bin:$CX_ROOT/libexec:${PATH:-/usr/bin:/bin:/usr/sbin:/sbin}" export WINEDLLPATH="$CX_ROOT/lib/wine/x86_64-unix:$CX_ROOT/lib/wine/x86_64-windows:$CX_ROOT/lib/wine/i386-windows${WINEDLLPATH:+:$WINEDLLPATH}" export DYLD_FALLBACK_LIBRARY_PATH="$CX_ROOT/lib64:$CX_ROOT/lib${DYLD_FALLBACK_LIBRARY_PATH:+:$DYLD_FALLBACK_LIBRARY_PATH}" export MVK_CONFIG_LOG_LEVEL="${MVK_CONFIG_LOG_LEVEL:-0}" exec "$REAL_WINE" "$@" And wineserver with this: #!/bin/sh set -eu CX_ROOT="/Applications/CrossOver.app/Contents/SharedSupport/CrossOver" REAL_WINESERVER="$CX_ROOT/bin/wineserver" export CX_ROOT export PATH="$CX_ROOT/bin:$CX_ROOT/libexec:${PATH:-/usr/bin:/bin:/usr/sbin:/sbin}" export WINEDLLPATH="$CX_ROOT/lib/wine/x86_64-unix:$CX_ROOT/lib/wine/x86_64-windows:$CX_ROOT/lib/wine/i386-windows${WINEDLLPATH:+:$WINEDLLPATH}" export DYLD_FALLBACK_LIBRARY_PATH="$CX_ROOT/lib64:$CX_ROOT/lib${DYLD_FALLBACK_LIBRARY_PATH:+:$DYLD_FALLBACK_LIBRARY_PATH}" export MVK_CONFIG_LOG_LEVEL="${MVK_CONFIG_LOG_LEVEL:-0}" exec "$REAL_WINESERVER" "$@" Then: chmod +x "$RUNTIME/wine64" chmod +x "$RUNTIME/wineserver" After that, Whisky was still the app I used to manage/launch the bottle, but the actual Wine runtime underneath was CrossOver Wine 11. Verify: WINEPREFIX="$BOTTLE" "$RUNTIME/wine64" --version Expected: wine-11.0... Step 4: Add CrossOver compatibility metadata to the Whisky bottle I also added a cxbottle.conf file directly inside the Whisky bottle. Path: "$BOTTLE/cxbottle.conf" Content: ;; CrossOver compatibility marker for launching this Whisky bottle ;; through CrossOver's Wine launcher. [Bottle] "Version" = "26.2.0.39821" "Timestamp" = "20260604T163056Z" "Description" = "WhiskySteam" "Template" = "win10_64" "WindowsVersion" = "win10" "MenuMode" = "ignore" "AssocMode" = "ignore" This made the bottle easier to launch/diagnose with CrossOver’s tools too. I also created a symlink so CrossOver could see the Whisky bottle: mkdir -p "$HOME/Library/Application Support/CrossOver/Bottles" ln -s "$BOTTLE" "$HOME/Library/Application Support/CrossOver/Bottles/WhiskySteam" Then this worked: "/Applications/CrossOver.app/Contents/SharedSupport/CrossOver/bin/wine" \ --bottle WhiskySteam \ --scope private \ cmd /c ver Expected: Microsoft Windows 10.0.19045 Step 5: Clean reinstall Steam, but keep games and login data This part mattered a lot. Before the final successful run, my Steam folder had become polluted by old wrapper experiments and CEF shim attempts. So I did a clean Steam reinstall. I moved the old Steam folder away: mv "$STEAMDIR" "$STEAMDIR.backup" Then downloaded the official Steam installer: curl -L -o SteamSetup.exe "https://cdn.akamai.steamstatic.com/client/installer/SteamSetup.exe" Installed it into the same bottle: "/Applications/CrossOver.app/Contents/SharedSupport/CrossOver/bin/wine" \ --bottle WhiskySteam \ --scope private \ SteamSetup.exe /S Then I restored only the important user/game folders from the backup: cp -a "$STEAMDIR.backup/steamapps" "$STEAMDIR/" cp -a "$STEAMDIR.backup/config" "$STEAMDIR/" cp -a "$STEAMDIR.backup/userdata" "$STEAMDIR/" This preserved installed games, Steam library metadata, and user data. Step 6: Launch Steam and let it fully update I launched Steam with the CrossOver Wine runtime: cd "$STEAMDIR" "/Applications/CrossOver.app/Contents/SharedSupport/CrossOver/bin/wine" \ --bottle WhiskySteam \ --scope private \ Steam.exe Steam performed two update phases. First it updated from the old installer bootstrap. Then it pulled the current Win64 Steam client and CEF package. The important final log lines were in: "$STEAMDIR/logs/bootstrap_log.txt" I saw: Startup - updater built Jun 9 2026 14:11:24 Windows 10.0.19045.0 Verification complete And in: "$STEAMDIR/logs/steamui_html.txt" I saw: Client version: 1781041600 Started webhelper process BrowserReady In: "$STEAMDIR/logs/webhelper.txt" I saw steamwebhelper.exe running from: C:\Program Files (x86)\Steam\bin\cef\cef.win64\steamwebhelper.exe with: -buildid=1781041600 Step 7: Confirm steamwebhelper is alive This command showed the important processes: ps aux | rg -i 'steam.exe|steamwebhelper|steamservice|wine|wineserver' The good result was multiple living steamwebhelper.exe processes, including renderer/network/storage processes. Example: Steam.exe steamwebhelper.exe -buildid=1781041600 steamwebhelper.exe --type=renderer steamwebhelper.exe --type=utility --utility-sub-type=network.mojom.NetworkService steamwebhelper.exe --type=utility --utility-sub-type=storage.mojom.StorageService That means Steam UI is actually alive, not just the old bootstrapper. So if your logs say BrowserReady and steamwebhelper is alive, but you see no window, check whether Steam created an off-screen window. How to verify the final Steam version Inside Steam: Steam -> Check for Steam Client Updates It should say the client is up to date. From logs: rg -n 'Client version|buildid|updater built|Windows 10' "$STEAMDIR/logs" Useful files: Steam/logs/bootstrap_log.txt Steam/logs/webhelper.txt Steam/logs/steamui_html.txt Steam/package/steam_client_win64.manifest My final manifest contained: "version" "1781041600" "ostype" "win10" Can I launch from Whisky normally after this? Yes. After replacing Whisky’s Wine runtime wrapper, I could still use Whisky normally. Double-clicking from Whisky should use the patched runtime, because Whisky calls its own Libraries/Wine/bin/wine64 , and that now forwards to CrossOver Wine 11. No special Steam launch script was required after the fix. Important warnings Back up first. This is not an official Whisky fix. Whisky is not really maintained for this current Steam behavior, and Steam can change again. Do not delete CrossOver after doing this. Whisky is now depending on CrossOver’s Wine runtime. Also, if Whisky updates or redownloads its Wine libraries, it may overwrite the wrapper files. If Steam breaks again after a Whisky update, check: "$HOME/Library/Application Support/com.isaacmarovitz.Whisky/Libraries/Wine/bin/wine64" --version If it no longer reports Wine 11 / CrossOver Wine, your wrapper was replaced. Final result The final achievement: I was able to update Windows Steam inside Whisky on macOS to the current Steam client, with working Steam UI and steamwebhelper , using CrossOver Wine 11 underneath Whisky. This allowed me to use the newer Steam components required by games/tools depending on steamFriend17 , including Project Doors Demo. So the practical fix was: Whisky UI + existing Whisky bottle but CrossOver Wine 11 as the runtime plus clean Steam reinstall/update Not old Steam, not no-browser mode, not headless Steam. Actual updated Steam with UI. P.S. Important fix if Whisky double-click does nothing After I got Steam working from Terminal, I noticed that launching Steam by double-clicking it inside Whisky still did nothing. The Steam client itself was fine. The problem was that CrossOver’s launcher could not find the bottle when it was started from Whisky’s GUI environment. The Whisky log showed: Unable to find the 'WhiskySteam' bottle: bottle 'WhiskySteam' not found in '' This happened because CrossOver’s bin/wine expects to know where private CrossOver bottles are stored. In Terminal, this may work automatically because $HOME and CrossOver’s environment are normal. But when launched through Whisky, the environment can be incomplete, so CrossOver sees an empty bottle path. The fix was to explicitly export CX_BOTTLE_PATH and CX_MANAGED_BOTTLE_PATH inside the Whisky Wine wrapper. My final wine / wine64 wrapper looked like this: #!/bin/sh set -eu CX_ROOT="/Applications/CrossOver.app/Contents/SharedSupport/CrossOver" REAL_WINE="$CX_ROOT/bin/wine" export CX_ROOT export HOME="${HOME:-/Users/lerfich}" export CX_BOTTLE_PATH="${CX_BOTTLE_PATH:-/Users/lerfich/Library/Application Support/CrossOver/Bottles}" export CX_MANAGED_BOTTLE_PATH="${CX_MANAGED_BOTTLE_PATH:-/Library/Application Support/CrossOver/Bottles}" export PATH="$CX_ROOT/bin:$CX_ROOT/libexec:${PATH:-/usr/bin:/bin:/usr/sbin:/sbin}" export WINEDLLPATH="$CX_ROOT/lib/wine/x86_64-unix:$CX_ROOT/lib/wine/x86_64-windows:$CX_ROOT/lib/wine/i386-windows${WINEDLLPATH:+:$WINEDLLPATH}" export DYLD_FALLBACK_LIBRARY_PATH="$CX_ROOT/lib64:$CX_ROOT/lib${DYLD_FALLBACK_LIBRARY_PATH:+:$DYLD_FALLBACK_LIBRARY_PATH}" export MVK_CONFIG_LOG_LEVEL="${MVK_CONFIG_LOG_LEVEL:-0}" case "${WINEPREFIX:-}" in */997CAB56-A21C-4FAB-9DB0-326FC26DE497) exec "$REAL_WINE" --bottle WhiskySteam --scope private "$@" ;; *) exec "$CX_ROOT/lib/wine/x86_64-unix/wine" "$@" ;; esac Replace: /Users/lerfich with your macOS username path, and replace: 997CAB56-A21C-4FAB-9DB0-326FC26DE497 with your own Whisky bottle UUID. Also make sure this symlink exists: mkdir -p "$HOME/Library/Application Support/CrossOver/Bottles" ln -s "$BOTTLE" "$HOME/Library/Application Support/CrossOver/Bottles/WhiskySteam" Where: BOTTLE="$HOME/Library/Containers/com.isaacmarovitz.Whisky/Bottles/YOUR-BOTTLE-UUID" After changing the wrapper, fully quit Whisky with Cmd+Q and reopen it. Whisky may keep old launch state while it is already running. One more detail: Whisky may call wine , not only wine64 , when launching pinned programs. So I made both files point to the same wrapper: cp wine64 wine chmod +x wine wine64 This fixed double-click launching from Whisky.

This signal has not been scored yet.