https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #15 from stormtrackertony@gmail.com --- (In reply to Andrew Nguyen from comment #14)
(In reply to stormtrackertony from comment #11)
@Andrew Thanks for the testing. It's definitely helpful! Although, I think it's still a little premature to completely rule out a virtualization bug. After all, AWS EC2 t1.micro instances is still a form of virtualization. I would like to reproduce this error on an actual Windows install before finalizing the conclusion that it happens on Windows. (Which I may be able to confirm myself when I find where I put that old laptop)
While successfully reproducing the crash on Windows with bare metal would be the ultimate proof, attributing the crashes I observed to a virtualization bug in the EC2 environment doesn't make sense to me because the data I collected is completely consistent with the backtraces you've attached, which I presume you've obtained from a non-virtualized environment.
The thing is, several WINE 8.x versions crash at that point but it says the fault is ldsl ....Several WINE 9.x versions crasg at the same point, but say the fault is vcmpps...Your AWS Windows Server 2019 errors at that point with an illegal instruction, but does not specify what it is.
Looking at my wine-9.0 and wine-9.12 backtraces and your wine-9.0 and wine-8.0.1 backtraces, I see they all report the same EIP 0x0043a534 with the same decoded vcmpps instruction (apart from the wine-8.0.1 backtrace, for which Zeb has explained the difference).
The Windows event log information also matches up, as the fault offset 0x0003a534, when compared against the image base offset of 0x00400000, matches exactly the faulting EIP in the Wine backtraces.
The fact that the programmer has double checked and confirmed that the compilation is set to use SSE2 only and no evidence of AVX in the code, then where is it coming from (if AVX is indeed the issue)?
With many actual Windows users upgrading the software and none yet to report the issue, it's hard to rule any possibility out just yet.
Based on the information I can see, it's hard to draw a conclusion that could implicate Wine in the crash.
Basically, what I'm referring to is the broader issue of handling exceptions. My understanding is the broad goal of WINE is not to simply be a code reader, but to replicate the behavior of Windows. Even if a software has a legit bug in it's code, if Windows is able to handle that bug in a manner that somehow corrects it or bypasses it to keep the software going, while WINE crashes the program, then there's still an indirect issue with WINE. The bug in the software would be the direct problem, but WINE would have an indirect problem in that it does not deal with the bug in the same manner that Windows does...Simply put, if a software bug doesn't crash the software on Windows, then it should not crash the software on Wine.
That's what is yet to be determined. It's clear now that some AVX instructions have found their way into this software that aren't supposed to be there. But we're yet to see how Windows handles the situation when AVX is not supported. If, by chance, Windows is able to work around it and keep the software going, then WINE, AWS EC2, etc. need to be programmed to perform that same work-around.
Perhaps the biggest question here is "How did AVX instructions get there in the first place when it's supposed to be?" If Visual Studio 2022 is incorrectly adding it, then there's probably a lot of other softwares with the same issue. All the more reason that WINE would want to find the work-around, should one exist.
That's why it's important to know for sure how Windows handles a situation instead of just assuming.