October 2026 - Wine-Bugs - list.winehq.org

[Bug 60534] New: Skyrim SE: Assertion `view->protect & VPROT_SYSTEM' failed.
by WineHQ Bugzilla Oct. 18, 2026

Oct. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60534 Bug ID: 60534 Summary: Skyrim SE: Assertion `view->protect & VPROT_SYSTEM' failed. Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: winebugs(a)63bit.net Target Milestone: --- Distribution: --- Created attachment 82395 --> http://bugs.winehq.org/attachment.cgi?id=82395 Last N lines of +virtual log to fit under the file size limit A modded Skyrim SE setup worked fine until 11.20, so this is a regression. I have not yet bisected the commits for 11.20. If there is a suspected commit happy to try reverting it. The game launches fine, can click to continue or start new game. The game will load, and as it is trying to start rendering the first scene frame, the game crashes reliably with "../wine/dlls/ntdll/unix/virtual.c:1502: create_view: Assertion `view->protect & VPROT_SYSTEM' failed." The game is using dxvk and proton vkd3d, as well as community shaders. Other SKSE plugins installed. I've attached a +virtual log. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 60535] New: loader/preloader.o: collect2: error: ld returned 1 exit status
by WineHQ Bugzilla Oct. 18, 2026

Oct. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60535 Bug ID: 60535 Summary: loader/preloader.o: collect2: error: ld returned 1 exit status Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: loader Assignee: wine-bugs(a)list.winehq.org Reporter: patrick+winehq.org(a)laimbock.com Target Milestone: --- Distribution: --- Created attachment 82396 --> http://bugs.winehq.org/attachment.cgi?id=82396 Log lines of loader/ from wine-11.20 build failure on F45 Building wine 11.20 (no staging) on Fedora 45 x86_64 with gcc-16.2.1, glibc-2.44 fails while building it on Fedora 44 succeeds. Shortened error: gcc -m64 -o loader/wine-preloader loader/preloader.o loader/preloader_mac.o -nostartfiles -nodefaultlibs -static -Wl,-Ttext=0x7d7d00000000 loader/preloader.o: in function `wld_vsprintf': ... /builddir/build/BUILD/wine-11.20-build/wine-11.20/loader/preloader.c:1151:(.text+0xc2b): additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status Log attached. A full build log of wine 11.20+staging+patches with the same error is at: https://download.copr.fedorainfracloud.org/results/patrickl/wine-staging-de… Please let me know if you need more information. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 57367] New: DLNest crash due to unimplemented function
by WineHQ Bugzilla Oct. 18, 2026

Oct. 18, 2026

https://bugs.winehq.org/show_bug.cgi?id=57367 Bug ID: 57367 Summary: DLNest crash due to unimplemented function Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: l12436.tw(a)gmail.com Distribution: --- DLNest new 2.0 version use dotnet and shown following message Unimplemented function ntdll.dll.NtCreateWaitCompletionPacket called at address 00006FFFFFC5F038 (thread 0140), starting debugger... which is seems like unimplemented in wine -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 18

[Bug 60533] New: partially implemented stub .. finds the adapter, but cannot open it
by WineHQ Bugzilla Oct. 18, 2026

Oct. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60533 Bug ID: 60533 Summary: partially implemented stub .. finds the adapter, but cannot open it Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wpcap Assignee: wine-bugs(a)list.winehq.org Reporter: rens.groenewegen(a)xs4all.nl Target Milestone: --- Distribution: --- I am trying to get an 32 bit packet capturing app to work. ( function: it checks for a checksum send by the client game, and validates it for the game server ) everything goes pretty well (as in: it recognizes what I have in the box ... ) but still fails to open the adapter. apparently blaming it on a partial stub ( i believe thats a incomplete implementation ?? ) NIC List: 1. \Device\NPF_{00000002-0000-0000-0000-4E6574446576} (eth3) 2. \Device\NPF_{00000003-0000-0000-0000-4E6574446576} (br0) 3. \Device\NPF_{00000004-0000-0000-0000-4E6574446576} (vnet0) 4. \Device\NPF_{00000005-0000-0000-0000-4E6574446576} (vnet1) 5. \Device\NPF_{00000001-0000-0000-0000-4E6574446576} (lo) 6. \Device\NPF_{00000006-0000-0000-0000-4E6574446576} (virbr0) 0164:fixme:wpcap:pcap_open "\\Device\\NPF_{00000002-0000-0000-0000-4E6574446576}", 65536, 1, 100, 00000000, 0012FC84: partial stub Unable to open the adapter. (null) is not supported by WinPcap itsme:vmhost3.fritz.box:[/home/itsme/.wine/drive_c/serv0-46800] = wine -V Application could not be started, or no application associated with the specified file. ShellExecuteEx failed: File not found. itsme:vmhost3.fritz.box:[/home/itsme/.wine/drive_c/serv0-46800] = wine --help Usage: wine PROGRAM [ARGUMENTS...] Run the specified program wine --help Display this help and exit wine --version Output version information and exit itsme:vmhost3.fritz.box:[/home/itsme/.wine/drive_c/serv0-46800] = wine --version wine-10.10 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 60532] New: Black Desert Online: starting in borderless fullscreen leaves frame-sized insets until switching fullscreen modes
by WineHQ Bugzilla Oct. 18, 2026

Oct. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60532 Bug ID: 60532 Summary: Black Desert Online: starting in borderless fullscreen leaves frame-sized insets until switching fullscreen modes Product: Wine Version: 11.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)list.winehq.org Reporter: ax+3lzp806u(a)fxzx.ident.com.es Target Milestone: --- Distribution: --- Created attachment 82394 --> http://bugs.winehq.org/attachment.cgi?id=82394 winedebug log ## Steps to reproduce 1. Configure Black Desert Online to start in borderless fullscreen mode. 2. Exit and launch the game again. 3. Observe the empty black strip at the top of the game window. The game image occupies a smaller area; its contents appear compressed into that area rather than cropped. 4. In the game settings, switch to fullscreen, then back to borderless fullscreen. 5. The image now fills the window. Restarting directly in fullscreen also displays correctly. ## Expected behavior Starting directly in borderless fullscreen fills the window, as it does after switching from fullscreen back to borderless fullscreen. ## Window geometry The top-level X11 window is at `(0,0)`, has size `1536×960`, and has zero X11 border width in both states. Its XID remains the same across the mode switch. Its single child also retains the same XID, but its geometry changes: | State | Child size | Child position relative to the top-level window | |---|---|---| | Started in borderless fullscreen, black strip visible | 1528×926 | +4+30 | | After fullscreen → borderless fullscreen | 1536×960 | +0+0 | In the first state, this leaves 4 pixels on the left, 4 on the right, 30 at the top, and 4 at the bottom. ## Observed Wine trace The following excerpts are from one logged run. In that run, the game HWND is `0x701dc`, the top-level XID is `0x3400005`, and the client XID is `0x3c0006a`. During startup, the trace first reports style `84cf0000` and client rectangle `(4,30)-(1532,956)`. It then records `GWL_STYLE` and `GWL_EXSTYLE` being set to zero: ```text 72433.563:0acc:0ad0:trace:win:set_window_long_internal 0x701dc -16 0 W 72433.563:0acc:0ad0:trace:win:set_window_long_internal 0x701dc -20 0 W ``` The subsequent `calc_winpos` entry requests `1536×960` with flags `00001a00` (without `SWP_FRAMECHANGED`). The style reported there is `04000000`. The following `X11DRV_WindowPosChanged` entry still reports: ```text window (0,0)-(1536,960) client (4,30)-(1532,956) visible (0,0)-(1536,960) flags 80001a0b ``` The client X11 geometry request is then: ```text 72434.402:0acc:0ad0:trace:x11drv:client_surface_update_geometry client window 0x701dc/3c0006a, requesting position 4,30 size 1528,926 mask 0xf ``` During the manual fullscreen switch, a `calc_winpos` entry for the same HWND requests `1536×960` with flags `00001870`, which include `SWP_FRAMECHANGED`. The next entries show the client rectangle and child geometry changing: ```text 72548.891:0acc:0ad0:trace:win:calc_ncsize hwnd 0x701dc old win (0,0)-(1536,960) old client (4,30)-(1532,956) new win (0,0)-(1536,960) new client (0,0)-(1536,960) 72548.891:0acc:0ad0:trace:x11drv:client_surface_update_geometry client window 0x701dc/3c0006a, requesting position 0,0 size 1536,960 mask 0xf ``` After switching back to borderless fullscreen, the client rectangle remains `(0,0)-(1536,960)` and the black strip is absent. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 60531] New: RollerCoaster Tycoon 1 and 2: some icons appear black in Load/Save Game dialogs
by WineHQ Bugzilla Oct. 18, 2026

Oct. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60531 Bug ID: 60531 Summary: RollerCoaster Tycoon 1 and 2: some icons appear black in Load/Save Game dialogs Product: Wine Version: 11.18 Hardware: x86-64 URL: https://store.steampowered.com/app/285310/RollerCoaste r_Tycoon_Deluxe/ OS: Linux Status: NEW Keywords: regression Severity: minor Priority: P2 Component: win32u Assignee: wine-bugs(a)list.winehq.org Reporter: gyebro69(a)gmail.com CC: zzhang(a)codeweavers.com Target Milestone: --- Regression SHA1: 25f928ad0713200939123875e6bb4a5626651339 Distribution: --- Created attachment 82392 --> http://bugs.winehq.org/attachment.cgi?id=82392 Load game dialog Some icons in the Load Game and Save Game dialogs of RollerCoaster Tycoon 1 and 2 are rendered black or much darker than expected. See the attached screenshot. Reproduced with the GOG and Steam versions. Demo version doesn't have load/save function. The regression was introduced in Wine 11.18. Bisect identified the following commit: 25f928ad0713200939123875e6bb4a5626651339 win32u: Add some special cases for CreateCompatibleBitmap() with a display DC. The issue is still present in Wine 11.20. The commit reverts cleanly on that version, and reverting it fixes the icon rendering in both games. The same commit fixed a graphics issue I reported in Return to Krondor (bug #60296). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 60397] New: RtlWaitOnAddress: a wake racing a timeout leaves a stale thread alert that ends the thread's next wait early (Warhammer 40,000: Space Marine 2 crashes mid-mission)
by WineHQ Bugzilla Oct. 18, 2026

Oct. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60397 Bug ID: 60397 Summary: RtlWaitOnAddress: a wake racing a timeout leaves a stale thread alert that ends the thread's next wait early (Warhammer 40,000: Space Marine 2 crashes mid-mission) Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)list.winehq.org Reporter: eggnet(a)gmail.com Target Milestone: --- Distribution: --- RtlWakeAddressSingle() and RtlWakeAddressAll() take a waiter's entry off the queue under the queue spinlock, but only alert the waiter (NtAlertThreadByThreadId) after releasing the lock. When the waiter's wait ends in that window, three things go wrong in RtlWaitOnAddress() (dlls/ntdll/sync.c): 1. Use after return. The waiter checks entry.addr without the lock. The waker clears entry->addr and then calls list_remove() on the entry, which lives on the waiter's stack. A waiter that sees the address cleared skips the locked section, returns, and reuses that stack while the waker is still reading entry->next/prev and writing through them. This needs the waker to be preempted in a window of a few instructions, so it is rare, but it is memory corruption. 2. Lost wake. The waiter returns STATUS_TIMEOUT although a wake was aimed at it. For RtlWakeAddressSingle() no other waiter receives that wake. 3. Stale alert. The waker's NtAlertThreadByThreadId() arrives with nobody waiting for it and stays pending. The thread's next NtWaitForAlertByThreadId() then returns immediately, whatever it is waiting for: typically a SleepConditionVariableCS()/SleepConditionVariableSRW() with an infinite timeout on an unrelated condition variable, which wakes up spuriously. Zero-timeout waits make this common: they are queued like any other wait and time out immediately, so a concurrent wake easily picks one. Spinlock back-offs that convert a short random delay to whole milliseconds (gperftools' SpinLockDelay on Windows, used by tcmalloc) pass 0 most of the time. Documented behaviour - WaitOnAddress may return early, and the documented causes include "A previous wake on the same address was abandoned" (https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-wa…) Wine's per-thread alert instead ends the thread's next wait on any address or condition variable. - WakeByAddressSingle "wakes the first thread to wait", and "other waiting threads continue to wait" (https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-wa…) A wake handed to a thread that is already timing out is lost for the thread actually waiting. - For a zero timeout, the usual Win32 rule applies, e.g. SleepConditionVariableCS: "If dwMilliseconds is zero, the function tests the states of the specified objects and returns immediately" (https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-sl…) Real-world impact Warhammer 40,000: Space Marine 2 (Steam 2183900) crashes mid-mission under Proton, about once per hour of play (https://github.com/ValveSoftware/Proton/issues/8072) Its libtcmalloc_minimal.dll back-off calls WaitOnAddress() with a timeout that rounds down to 0 ms; an instrumented ntdll counted over 2,000 zero-timeout waiters dequeued as they timed out in 44 minutes of play. The game then does an unlooped SleepConditionVariableCS(INFINITE) whose early return leaves a file-read completion callback pointing into a dead stack frame (access violation in resFILE_LOADER at Retail.exe+0x2158FEE). The game is at fault for not looping, but the spurious wakeup is a Wine artifact; the crash has not been reported on Windows. With a prototype fix on my machine: about 4 hours of play without a crash, against 8 crashes in about 7 h 20 min before, same kernel and game build. Details and measurements are in the two comments linked below. Reproducers - Stress program: 8 worker threads. Each takes a tcmalloc-style spinlock (a zero-timeout WaitOnAddress() poll in a CAS loop, released with WakeByAddressSingle(); 4 more threads hammer the same lock) and then does a single, unlooped SleepConditionVariableCS(INFINITE) on its own condition variable, completed by a dedicated thread. It counts returns while the predicate is still false. In 15 s on Proton Experimental 11.0-20260924: 529,155 waits, 69,195 returned early (about 13%). With the prototype fix: 0, same throughput. - Conformance-style test: a thread loops on RtlWakeAddressSingle()/RtlWakeAddressAll() while the main thread does up to 20,000 RtlWaitOnAddress() calls on that address with a timeout of 0 or -1 (100 ns), and after each one a 100 ns wait on a different address, which must time out. On stock Wine, 1 to 26 of the 20,000 waits on the other address returned early, in 11 of 12 cases over three runs. With the prototype fix, 0. Fix approach that worked a) Check under the queue lock whether the entry was dequeued; a waker that has released the lock is done with the entry. (Fixes 1.) b) Don't queue zero-timeout waits: compare the value and return STATUS_SUCCESS or STATUS_TIMEOUT. c) A waiter that finds itself dequeued after its wait timed out reports the wake, and takes the in-flight alert with a short bounded NtWaitForAlertByThreadId() (1 ms was enough in every measured case) rather than waiting for it indefinitely. (Fixes 2, and 3 in practice.) d) An alert received while the waiter is still queued cannot be a wake for the current wait, since wakers dequeue first; ignore it and keep waiting until the original deadline (convert a relative timeout to an absolute one once). Safety net for whatever c) misses and for alerts left over from thread id reuse. Note that this also means NtAlertThreadByThreadId() no longer ends a RtlWaitOnAddress() wait, which it does on Windows; that is an undocumented interaction and no documented interface offers it. With a)-d), ntdll:sync and kernel32:sync are otherwise unchanged. Alerting under the queue lock would also close the race but would put a futex wake inside the spinlock on the path of every SRW lock, critical section and condition variable wake. Note on provenance: the investigation was done with the help of an LLM tool, and the prototype fix, stress program and test were generated with it. Per the Clean Room Guidelines I am not submitting any of that code; this report describes the problem and the approach so that the fix can be written by a Wine developer. All measurements above were taken on my machine (Bazzite 44, kernel 7.2.7, Ryzen 7 9800X3D, RX 9070 XT). References - Analysis, crash dumps and in-game data: https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-5852529635 - Revised prototype fix and test results: https://github.com/ValveSoftware/Proton/issues/8072#issuecomment-5858321198 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 60530] New: winmm: waveOutGetVolume fails with MMSYSERR_INVALHANDLE when given a device ID (MTGO plays no sound)
by WineHQ Bugzilla Oct. 18, 2026

Oct. 18, 2026

http://bugs.winehq.org/show_bug.cgi?id=60530 Bug ID: 60530 Summary: winmm: waveOutGetVolume fails with MMSYSERR_INVALHANDLE when given a device ID (MTGO plays no sound) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs(a)list.winehq.org Reporter: silinarii(a)gmail.com Target Milestone: --- Distribution: --- dlls/resampledmo/resampler.c implements IWMResamplerProps::SetHalfFilterLength as a stub that returns E_NOTIMPL. On Windows the call succeeds (it sets the resampling quality, 1-60). NAudio's MediaFoundationResampler, the standard way to convert audio formats in NAudio, the most widely used .NET audio library, calls SetHalfFilterLength right after SetInputType/SetOutputType when it creates the transform. .NET COM interop turns the E_NOTIMPL into a COMException on NAudio's playback thread, so no audio is ever passed through ProcessInput/ProcessOutput and that output stays silent. Impact: Magic: The Gathering Online converts every sound effect (16-bit stereo WAV to a 44.1 kHz float mono mixer) with MediaFoundationResampler, so it has no sound at all under Wine and Proton. This very likely affects every .NET application that resamples with NAudio, and any native application that treats the failure as fatal. Trace (WINEDEBUG=trace+dmo,fixme+dmo) for each sound: trace:dmo:transform_SetInputType ... trace:dmo:transform_SetOutputType ... trace:dmo:unknown_QueryInterface ... iid {e7e9984f-f09f-4da4-903f-6e2e0efe56b5} (IWMResamplerProps) fixme:dmo:resampler_props_SetHalfFilterLength iface ..., count 60 stub! followed by no ProcessInput/ProcessOutput calls on that transform. Expected: SetHalfFilterLength accepts the value (returning S_OK). The FFmpeg-based resampler can choose its own filter, so ignoring the hint is enough for these applications; with that change MTGO's sound works. IWMResamplerProps::SetUserChannelMtx is the same kind of stub and may cause similar failures. Note: this was found while debugging MTGO with the help of an AI assistant. No code is attached; the description above is the whole report. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 60529] New: winmm: waveOutGetVolume fails with MMSYSERR_INVALHANDLE when given a device ID (MTGO plays no sound)
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60529 Bug ID: 60529 Summary: winmm: waveOutGetVolume fails with MMSYSERR_INVALHANDLE when given a device ID (MTGO plays no sound) Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winmm&mci Assignee: wine-bugs(a)list.winehq.org Reporter: silinarii(a)gmail.com Target Milestone: --- Distribution: --- Version: 11.19 (also current master) On Windows, the first parameter of waveOutGetVolume() may be either an open HWAVEOUT or a device identifier ("hwo: Handle to an open waveform-audio output device. This parameter can also be a device identifier." per MSDN). Calling waveOutGetVolume(0, &vol) therefore returns MMSYSERR_NOERROR and the volume of device 0. In Wine, dlls/winmm/waveform.c only accepts handles: WINMM_GetDeviceFromHWAVE() fails for a device ID, so the call returns MMSYSERR_INVALHANDLE and leaves the output untouched. Impact: Magic: The Gathering Online reads the "Windows volume" with waveOutGetVolume(IntPtr.Zero, out vol), ignores the return code and treats the untouched value as 0, so it skips every sound before playing it. Any program using this common idiom gets no volume (or, if it uses the value, silence). waveOutSetVolume() very likely has the same problem with device IDs. Steps to reproduce: 1. Call waveOutGetVolume((HWAVEOUT)0, &vol) without opening a device. 2. Windows: returns 0 (MMSYSERR_NOERROR) with the device volume. Wine: returns 5 (MMSYSERR_INVALHANDLE). Observed with WINEDEBUG=+relay on MTGO: Call winmm.waveOutGetVolume(00000000,...) Ret winmm.waveOutGetVolume() retval=00000005 Expected: device IDs below waveOutGetNumDevs() are accepted (Wine's own HWAVE values have high bits set, so they don't collide). Note: this was found while debugging MTGO with the help of an AI assistant. No code is attached; the description above is the whole report. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 60518] New: GetRequestedRuntimeInfo crashes with pVersion=NULL and cchBuffer=0
by WineHQ Bugzilla Oct. 17, 2026

Oct. 17, 2026

http://bugs.winehq.org/show_bug.cgi?id=60518 Bug ID: 60518 Summary: GetRequestedRuntimeInfo crashes with pVersion=NULL and cchBuffer=0 Product: Wine Version: 11.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)list.winehq.org Reporter: thirtythreeforty(a)gmail.com Target Milestone: --- Distribution: --- Created attachment 82376 --> http://bugs.winehq.org/attachment.cgi?id=82376 Log of `WINEDEBUG=+mscoree,+seh wine "$HOME/Downloads/launch.msi"` The current Bay ROES installer (https://bayphoto.com/order/bay-roes/) runs a custom DLL during installation, which eventually calls GetRequestedRuntimeInfo with pVersion=NULL and cchBuffer=0 (probably trying to size an output buffer). The implementation does not check cchBuffer != 0 before doing a write to pVersion. (This write is trying to preserve v/V from the input buffer.) When pVersion is NULL, this crashes. Log of installation attempt is attached. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3