https://bugs.winehq.org/show_bug.cgi?id=56912
Bug ID: 56912 Summary: GR2Analyst 3 Weather Radar Software Product: Wine Version: 9.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: blocker Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: stormtrackertony@gmail.com Distribution: ---
Created attachment 76733 --> https://bugs.winehq.org/attachment.cgi?id=76733 backtrace of error
Latest version of this software loads but errors when trying to import radar data.
Shared the attached backtrace with the software developer and he responded:
The problem is here:
0x0043a534 gr2analyst+0x3a534: ldsl %eax,%esi
Which is trying to load a full 48-bit pointer into segment:register from a memory location. Win32 programs aren't allowed to mess with their segment registers.
I don't see that code anywhere in my asm listing files, so there are two possibilities:
1. The stack is getting corrupted and the return address from a function call is trashed, so the program tries to execute junk (which happens to be the LDS instruction). Of course, the question is "why doesn't this happen on real Windows"?
2. WINE has a bug that trashes the stack.
https://bugs.winehq.org/show_bug.cgi?id=56912
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #1 from Zeb Figura z.figura12@gmail.com --- The faulting instruction isn't ldsl (it would be ldsl if that instruction could take a register as a source argument, but it can't). The faulting instruction is actually vcmpps. The program probably requires AVX (or it mistakenly detects AVX when the processor doesn't support it). Does this program work on Windows without AVX?
https://bugs.winehq.org/show_bug.cgi?id=56912
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|blocker |normal CC| |dark.shadow4@web.de
--- Comment #2 from Fabian Maurer dark.shadow4@web.de --- Not a blocker
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #3 from stormtrackertony@gmail.com --- So far every direct Windows install has been reported to work. Not sure if any are without AVX. I don't have real Windows to test myself.
There is a 21 day free trial that is fully functional in case anyone would care to experiment with this. Small files and only takes a few seconds to install. To replicate the error:
First download and install the main software:
https://www.grlevelx.com/downloads/gr2analyst_3_setup.exe
Once installed, download and install the latest update:
https://www.grlevelx.com/downloads/gr2analyst_3_update_3300.exe
Then open software, click the "Iowa State" option on the popup requesting a source, then click the icon directly under the "file" tab (picture of a globe and computer screen). This is when the radar data should display on the map but instead the error crashes the program.
According to the developer, the only difference is the new version (which is not working) is compiled with Visual Studio 2022 and the old version (which does work) was with Visual Studio 2008.
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #4 from Zeb Figura z.figura12@gmail.com --- It works here, but that's on a machine with AVX support. I'm not sure if I have a machine old enough to not support AVX...
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #5 from stormtrackertony@gmail.com --- (In reply to Zeb Figura from comment #4)
It works here, but that's on a machine with AVX support. I'm not sure if I have a machine old enough to not support AVX...
Thank you for your help with this. When you say "it works here", do you mean on an actual Windows operating system with AVX support or with WINE on a computer with AVX support?
Just to make sure the problem is clear: The original install of the software (first link posted on my last reply) will load the radar data on actual Windows and on WINE....The new, updated version (second link from my last post) still loads radar data on actual Windows but throws an error on WINE (the map still displays on WINE, but it crashes when I click that button under the "file" tab to get the radar data).
My goal is to get that new version working with WINE. The software developer seems to think it's a bug in WINE since it works normally with actual Windows and he doesn't see anything in his code that would cause the error I'm getting in my WINE backtrace. He also said the only requirement is DirectX 11 and that it should work fine even on old systems (as far back as Windows Vista)
What I'm trying to determine is:
1. Does this error happen to everyone on WINE or is it just some deficiency with my particular system?
2. If it does affect all WINE users, is it a bug in WINE or is there a bug in the program that the developer is overlooking?
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #6 from Zeb Figura z.figura12@gmail.com --- (In reply to stormtrackertony from comment #5)
(In reply to Zeb Figura from comment #4)
It works here, but that's on a machine with AVX support. I'm not sure if I have a machine old enough to not support AVX...
Thank you for your help with this. When you say "it works here", do you mean on an actual Windows operating system with AVX support or with WINE on a computer with AVX support?
On Wine.
Just to make sure the problem is clear: The original install of the software (first link posted on my last reply) will load the radar data on actual Windows and on WINE....The new, updated version (second link from my last post) still loads radar data on actual Windows but throws an error on WINE (the map still displays on WINE, but it crashes when I click that button under the "file" tab to get the radar data).
Right, I did install the update. Hopefully I did it correctly.
My goal is to get that new version working with WINE. The software developer seems to think it's a bug in WINE since it works normally with actual Windows and he doesn't see anything in his code that would cause the error I'm getting in my WINE backtrace. He also said the only requirement is DirectX 11 and that it should work fine even on old systems (as far back as Windows Vista)
The program tries to execute an AVX instruction, and that's generating SIGILL. That implies the target processor doesn't support AVX (this can be easily confirmed by looking for the presence of "avx" in the "flags" line of /proc/cpuinfo).
The simplest theory is that the program (or bundled libraries) does depend on AVX. It's kind of easy to miss this since AVX is relatively old (2011 IIRC?) In order to test this one would need a Windows install on a processor that doesn't support AVX. I'm not sure I have access to such a machine.
Likely the default compilation flags and/or redists changed between Visual Studio 2008 and 2022.
It's also possible that the program is able to handle a lack of AVX, but is incorrectly detecting that Wine supports AVX. I find this a little unlikely—I think Wine's feature detection is in good shape—but it's possible.
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #7 from stormtrackertony@gmail.com --- Created attachment 76746 --> https://bugs.winehq.org/attachment.cgi?id=76746 backtrace from Wine version 8.0.1
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #8 from stormtrackertony@gmail.com --- Do you recall if you were able to see radar data on the map with the new version (instead of just a blank map?)
One thing I noticed that may or may not be important. Though the error happens in the same manner, the backtrace is different between Wine version 8.0.1 and 9.0...When the program developer first said the problem was ldsl , it was because of the backtrace on 8.0.1 (just attached in the post above)...It includes:
0x0043a534 gr2analyst+0x3a534: ldsl %eax,%esi
and does not even mention vcmpps...The backtrace I originally posted here was after upgrading to Wine 9.0 which replaced that ldsl line with:
0x0043a534 gr2analyst+0x3a534: vcmpps $0x0e, %xmm0, %xmm1, %xmm2
Does seeing this old file with ldsl mention change your thoughts?
Also, I have confirmed that my system does not support AVX. Though, my understanding is the program does not use AVX, but instead uses SSE2 instructions (which my system does support).
Interesting aspect to this is there was a significant speed improvement between the older Visual Studio 2008 compilation and the new Visual Studio 2022 compilation which the program developer could not explain. He said "Render times for radar data have been cut in half for the VS2022 compilation, but I'm not sure where the performance boost is coming from. Both are set to use SSE2 instructions, so that has not changed."
I'm not a programmer myself, so my knowledge is limited on this stuff. But I'm wondering if he could have somehow accidentally added AVX (or AVX2) instead of the intended SSE2. If so, that could potentially explain both the performance boost of the new version and why my system is crashing on it.....I mean, old version uses SSE2, which is supposed by my system and works on my system. New version is supposed to still use SSE2, yet does not work on my system, gives AVX error (not supported by my system) for some unknown reason and a mysterious significant performance boost in the software...Seems coincidental?
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #9 from stormtrackertony@gmail.com --- Also, here is the latest response from the software developer. He seems convinced that it's not an issue with his code. I'm looking for some of my old laptops to see if any are non-AVS systems with genuine Windows...
Programmer's repsonse:
"I verified that I chose SSE2 in the compiler options for VS 2022 and 2008, so no AVX instructions should be used. If VS2022 is generating AVX instructions then that's a bug in VS 2022. I doubt that's the case and I don't see vcmpps or cmpps in the asm listing from the compiler. I suspect that the stack in a call is being trashed and the return is jumping into junk, hence the different "instructions" causing the crash on different WINE versions. If there were AVX calls in the 2022 build, I have to believe it would have crashed as soon as the software opened, not waiting until radar data started polling.
In addition, I have looked at the generated code for both VS 2008 and 2022 and found out why 2022 is so much faster. 2008 is not inlining the function and member calls in my code. I don't know why 2008 isn't inlining the member calls properly. 2022 is inlining the calls *and* then optimizing the resulting code. Both compilers are set to "maximize speed", so they're free to generate as much code as needed (e.g. inline generated code) to accomplish the results. "
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #10 from Andrew Nguyen arethusa26@gmail.com --- I tested the GR2Analyst v3 application on AWS EC2 t1.micro instances, which do not have AVX instructions available. I confirmed that AVX instruction capability is unavailable for an instance launched from a Debian 12 AMI, as /proc/cpuinfo reports only the following flags:
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc rep_good nopl cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm pti
With an instance launched from a Windows Server 2019 Base AMI, I confirmed using CPU-Z that the instruction capabilities reported do not include AVX: MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, EM64T.
On the Debian 12 instance, I confirmed for wine-9.0 and wine-9.12 that the application crashes with an illegal instruction exception when performing the reproduction steps. The implicated instruction is the vcmpps instruction as previously noted.
On the Windows Server instance, performing the reproduction steps also results in the application terminating. The event log reported the following details:
Faulting application name: gr2analyst.exe, version: 3.3.0.0, time stamp: 0x667995de Faulting module name: gr2analyst.exe, version: 3.3.0.0, time stamp: 0x667995de Exception code: 0xc000001d Fault offset: 0x0003a534
The exception code corresponds to STATUS_ILLEGAL_INSTRUCTION, so the application probably died in the same way as on Wine.
Therefore, I think the application can unconditionally execute an AVX instruction even on Windows, so there's no evidence of a bug in Wine, and I think this bug should be closed as invalid.
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #11 from stormtrackertony@gmail.com --- @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)
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.
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.
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #12 from Zeb Figura z.figura12@gmail.com --- (In reply to stormtrackertony from comment #8)
Do you recall if you were able to see radar data on the map with the new version (instead of just a blank map?)
I think so? It's hard to tell, the map was mostly static. There was a timer ticking though.
One thing I noticed that may or may not be important. Though the error happens in the same manner, the backtrace is different between Wine version 8.0.1 and 9.0...When the program developer first said the problem was ldsl , it was because of the backtrace on 8.0.1 (just attached in the post above)...It includes:
0x0043a534 gr2analyst+0x3a534: ldsl %eax,%esi
and does not even mention vcmpps...The backtrace I originally posted here was after upgrading to Wine 9.0 which replaced that ldsl line with:
0x0043a534 gr2analyst+0x3a534: vcmpps $0x0e, %xmm0, %xmm1, %xmm2
Does seeing this old file with ldsl mention change your thoughts?
The faulting opcode sequence for the vcmpps instruction from the crash report is C5 F0 C2 D0 0E.
LDS is encoded as C5 plus a mod/r/m byte. A mod/r/m byte can encoded either a register or indirectly addressed memory. However, unlike most instructions that use a mod/r/m byte, due to its semantics the LDS instruction does not make sense with a register, only with memory (e.g. while "ldsl (%eax),%esi" makes sense; "ldsl %eax,%esi" does not.) Hence LDS with a register has always generated #UD (i.e. "invalid instruction" i.e. SIGILL).
When AVX was introduced it reused that part of the encoding space for other instructions, since it previously made no sense.
However, a naïve enough disassembler that (a) does not know about AVX, and (b) does not include enough validity checks to forbid LDS with a register, will try to interpret the bytes as C5 F0, and disassemble the instruction as "ldsl %eax,%esi".
Prior to Wine 8.3, winedbg had such a naïve disassembler with those flaws. In 8.3 we replaced it with an external library that knew about AVX. This is why there is a difference in how the instruction is decoded.
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #13 from Zeb Figura z.figura12@gmail.com --- I tried to look in static disassembly to find out whether that instruction is supposed to be there or whether we're indeed jumping to the middle of invalid memory or something. That instruction isn't there, it's in the middle of a .text section that's in the executable's mapped address space, but on disk the section is filled with zeroes. It's evidently jitted, and filled from some portion of memory that's also jitted.
Is this application embedding some scripting runtime or copy-protection scheme?
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #14 from Andrew Nguyen arethusa26@gmail.com --- (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.
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.
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #16 from stormtrackertony@gmail.com --- (In reply to Zeb Figura from comment #13)
I tried to look in static disassembly to find out whether that instruction is supposed to be there or whether we're indeed jumping to the middle of invalid memory or something. That instruction isn't there, it's in the middle of a .text section that's in the executable's mapped address space, but on disk the section is filled with zeroes. It's evidently jitted, and filled from some portion of memory that's also jitted.
Is this application embedding some scripting runtime or copy-protection scheme?
May be getting somewhere now! You wouldn't happen to know which .text section (or something I could share with the developer to point him in the right direction)?
I know he's not going to put much time into figuring it out until if/when we can document it happening on an actual Windows install. Even with previous versions of the software in years past, people have tried to troubleshoot issues of getting it to work on WINE and he would tell them "I only support direct Windows issues. You're on your own getting it to work with emulation. Just too much on my plate to be spending time dealing with issues on alternative platforms." That's why I'm a little surprised he's spent as much time as he already has reviewing code and such based on my WINE report. The quicker/easier it is for him to find, the better odds of him fixing it. Too much time/effort and it'll get pushed to the back burner until if/when actual Windows users start complaining. Keep in mind, he's not some hobbyist making a cheap weather app. This program is officially used at all the United States government National Weather Service offices, as well as emergency managers, TV stations and other high-profile clients. So this is the real deal with lots of official duties with managing that program.
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #17 from Zeb Figura z.figura12@gmail.com --- (In reply to stormtrackertony from comment #15)
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.
That's not how it works I'm afraid. AVX is a processor-level feature. If Windows were to "handle" it, it would need to embed an AVX emulator (like Linux's x87 emulator of yore), but Windows does not do that. (And if Windows embedded an AVX emulator, it would work on the AWS virtualization environment.)
More plausible is that AWS is performing CPU emulation of a processor that doesn't support AVX on a processor that does, and that emulation is buggy somehow. I'm not sure I find this particularly likely either, though.
Unfortunately I don't have access to any bare-metal Windows that's old enough to not support AVX but also new enough to support Vista.
By all evidence, the developer has attempted to target SSE2, and it's true that none of the statically disassembled code in the executable uses AVX instructions, but somehow some other component is using AVX instructions anyway.
(In reply to stormtrackertony from comment #16)
May be getting somewhere now! You wouldn't happen to know which .text section (or something I could share with the developer to point him in the right direction)?
It's just ".text". The actual entry point and statically available disassembly is in a section ".text1".
I wouldn't necessarily expect the developer to know the binary details of what's going on under the hood there, but possibly more helpful is: the contents of the .text section seem to be written from another jitted memory area dynamically allocated at runtime, and the contents of *that* memory area are written somewhere around 0x733759 [at least, that's where the VirtualProtect() is.]
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #18 from stormtrackertony@gmail.com --- Ugh, so close!! Found the old laptop (Turns out it was originally Windows 7 which I actually had upgraded to Windows 10). No AVX support but it does support SSE2. Exactly what we're looking for! Unfortunately, when I try to open the software, I get a DirectX Initialization error.
The software uses DirectX 11. According to Dxdiag, I have DirectX 12. I thought DirectX 11 was automatically included in Windows 10 and that DirectX 12 was also backwards compatible with software needing DX11. Guess I was mistaken? Now I've got to figure out how to get DX11 (or what's going wrong if it's already on my system)
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #19 from stormtrackertony@gmail.com --- From developer:
"I use Armadillo to protect the exe and handle registration keys ... and have used it for years, so I don't imagine it's causing this issue. Plus, I see no reason why it would use AVX instructions. What it will do is screw up any debugging attempt when looking at an exe file vs looking in memory. Armadillo takes my release build, created with Virtual studio here at my location, encrypts it and stores it as a payload to be decrypted into memory at runtime.
VS2022 is, obviously, new. I don't know why it would do any JIT stuff. "
https://bugs.winehq.org/show_bug.cgi?id=56912
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED
--- Comment #20 from Zeb Figura z.figura12@gmail.com --- This is the disassembly around the faulting instruction:
0x43a515: mov 0xc(%ebx),%edi 0x43a518: mov %esi,%ecx 0x43a51a: sub %eax,%ecx 0x43a51c: xorps %xmm5,%xmm5 0x43a51f: xorps %xmm4,%xmm4 0x43a522: xorps %xmm6,%xmm6 0x43a525: xorps %xmm7,%xmm7 0x43a528: nopl 0x0(%eax,%eax,1) 0x43a530: movups (%edi,%edx,4),%xmm1 => 0x43a534: vcmpgtps %xmm0,%xmm1,%xmm2 0x43a539: movaps %xmm2,%xmm0 0x43a53c: andps -0x40(%ebp),%xmm2 0x43a540: andps %xmm1,%xmm0 0x43a543: paddd %xmm2,%xmm5
(Note "vcmpgtps ..." is an alternate mnemonic for "vcmpps $0x0e, ...")
It's not garbage.
It's also not the same code that's written in the non-updated version, or if it is, it's written to a different place and I can't find it.
If the copy-protection hasn't changed between versions, then my only guess is that it's querying the CRT, which is apparently statically linked, and the CRT is somehow giving an indication that AVX is available. This is difficult to explain if the CRT is explicitly configured not to do that, but maybe the copy-protection is badly implemented and assumes AVX based on the CRT version or something.
I'm pretty convinced that the copy protection is requiring AVX and will fail on any processor that doesn't support it. Ultimately I am guessing that the developer is only going to be convinced if the program is tested on bare metal, and I don't have the time or equipment for that. This is my best ability to describe the problem and offer hypotheses.
Until there's good evidence that Wine is at fault I'm resolving this INVALID.
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #21 from stormtrackertony@gmail.com --- Zeb, I would definitely have to agree with you at this point. Even though we've not had a bare-metal confirmation, you've gone above and beyond expectation to document that an unintended AVX instruction has somehow made it into the updated GR2Analyst code. I thank you (and Andrew) both for the time and effort to help reach this conclusion!
Further, I'm now starting to believe that even though the error is likely to occur on actual bare-metal Windows with similar hardware, it's going to be hard to find a system to actually reproduce it (and rare, if ever, to be an issue for real world users.) Another program user was trying to test this with a bunch of old laptops and in all cases, the system either had AVX support and worked or either the hardware lacked D3D11 support needed to even open the software to begin with. According to his research, there's very few systems that are old enough to lack AVX support yet new enough to support the D3D11 requirement. Most of those that would be affected were built between 2010 and 2011 (as mine was). Guess I'm just unlucky (or either this is my sign that I'm well overdue for a system upgrade. lol)
What still baffles me the most is why the instruction does not appear until trying to load a radar file. I can display weather warnings, move/zoom around on the map, access menus, etc. for as long as I want with no problem. Then I try to load a radar data file and boom! Granted, I'm no programmer, so I'm kind of learning little bits as I go. Yet if copy protection is the problem source and the whole exe is copy protected, then why does it wait until that point rather than crashing immediately when opening the software? That's what's most mysterious to my old brain!
In any event, I'll share those disassembly results with the developer and it's up to him to decide whether he wants to pursue a fix for it or ignore it hoping no one else runs into the issue. Will let you know if he ever finds a fix. I thank you again and feel free to reach out anytime I can ever return the favor! Who knows, maybe you'll need me to test a software on this apparently rare, 2010 clunker of a computer I have! lol
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #22 from stormtrackertony@gmail.com --- Quick follow-up to share an interesting find... Check out this reported Virtual Studio 2022 bug earlier this year. Notice how a few comments down, a programmer was getting the exact AVX "vcmpgtps" generation despite having his code set to only use SSE2...As of the last official response from Virtual Studio on April 23, they've found a fix and is pending release.
https://developercommunity.visualstudio.com/t/An-AVX-instruction-is-generate...
Sure sounds like the exact issue to me! Not sure when they plan to release, but whenever they do, I'll update if that solved it. May be helpful to know as this bug could potentially affect all software compiled with the latest Virtual Studio 2022 version. Then if the issue shows up on another software, you'll know right away it's a Virtual Studio bug rather than spending time investigating it as a possible Wine bug.
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #23 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=56912
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #24 from Austin English austinenglish@gmail.com --- Actually closing.
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #25 from stormtrackertony@gmail.com --- Yes, please close as the problem is solved. It was indeed the Virtual Studio bug that was including unwanted AVX. Virtual studio has released a fix for this bug in version vs2022 17.11 and recompiling the software with this version no longer produces the unexpected AVX call. I can confirm that the software is now fully functional on Wine. Thank you all again!
https://bugs.winehq.org/show_bug.cgi?id=56912
--- Comment #26 from stormtrackertony@gmail.com --- Yes, please close as the problem is solved. It was indeed the Virtual Studio bug that was including unwanted AVX. Virtual studio has released a fix for this bug in version vs2022 17.11 and recompiling the software with this version no longer produces the unexpected AVX call. I can confirm that the software is now fully functional on Wine. Thank you all again!
-
WineHQ Bugzilla