https://bugs.winehq.org/show_bug.cgi?id=56361
Bug ID: 56361 Summary: Geovision Parashara's Light (PL9.exe) still crashes in wine Product: Wine Version: 9.2 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: yafoce6821@giratex.com Distribution: ---
Separating the bugs, on request from @Vijay Kamuju continuing from the discussion in Bug56299: https://bugs.winehq.org/show_bug.cgi?id=56299
Impacted Application: PL9.exe (Parashara's Light 9.0 from Geovision Software)
Bug56299 fixed the imm32.dll required stub.
However, the application still crashes spinning up the wine debugger after the initial splash screen.
I tried a wmic hack proposed by @Louis Lenders, but unfortunately no matter what amount I made wmic sleep, the splash screen would stay active by the same amount, and then it crashes as usual with the wine debugger spinning up.
Bug56299 has some relevant log files.
https://bugs.winehq.org/show_bug.cgi?id=56361
yafoce6821@giratex.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://parasharaslight.com | |/parasharas-light/ CC| |xerox.xerox2000x@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=56361
yafoce6821@giratex.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |infyquest@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #1 from Vijay Kamuju infyquest@gmail.com --- wmic should open a console just like cmd.exe
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #2 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Vijay Kamuju from comment #1)
wmic should open a console just like cmd.exe
Yeah, but I now realized that it could alse be that a command was piped to wmic.
Just checked and windows wmic support this:
echo 'os get name' |wmic.exe
finds correct value; on wine this just fails.
I'll see if I can copy over some code from e.g. findstr.exe or so, as that supports this piping in wine.
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #3 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 76105 --> https://bugs.winehq.org/attachment.cgi?id=76105 copy/paste (from findstr.c) hack
Hi, attached copy/paste (from findstr.c) hack, too lazy to clean it up. It makes something like "echo 'os get name' | wmic" work. If my previous comment is right, the patch should make it visible (FIXME:wmic) in the console what query wmic does. Could you attach console output after applying patch?
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #4 from yafoce6821@giratex.com --- (In reply to Louis Lenders from comment #3)
Created attachment 76105 [details] copy/paste (from findstr.c) hack
Hi, attached copy/paste (from findstr.c) hack, too lazy to clean it up. It makes something like "echo 'os get name' | wmic" work. If my previous comment is right, the patch should make it visible (FIXME:wmic) in the console what query wmic does. Could you attach console output after applying patch?
Compiled on 1b32ac45f821ee1fe06a3dc4f903a81a190216c7 (Release 9.3)
Output of unpatched version:
$ WINEPREFIX=~/wine/win10ltsc WINEARCH=win32 ./wine-src/wine start /d "C:\Geovision\PL9" "C:\Geovision\PL9\PL9.exe"
002c:fixme:ver:GetCurrentPackageId (0066FECC 00000000): stub 0034:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 0118:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 0130:fixme:ver:GetCurrentPackageId (0062FECC 00000000): stub wine: Unhandled page fault on read access to 00000004 at address 01563FCE (thread 0128), starting debugger... 0138:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 0140:fixme:ver:GetCurrentPackageId (0089FECC 00000000): stub 0148:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 003c:fixme:ver:GetCurrentPackageId (0068FECC 00000000): stub
Output of patched version
$ WINEPREFIX=~/wine/win10ltsc WINEARCH=win32 ./wine-src/wine start /d "C:\Geovision\PL9" "C:\Geovision\PL9\PL9.exe"
002c:fixme:ver:GetCurrentPackageId (0066FECC 00000000): stub 0034:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 0118:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 0130:fixme:wmic:wmain parsing L"bios get statu" 0130:fixme:ole:CoInitializeSecurity 00000000, -1, 00000000, 00000000, 0, 3, 00000000, 0, 00000000 stub 0130:fixme:ver:GetCurrentPackageId (0062FECC 00000000): stub 0138:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub wine: Unhandled page fault on read access to 00000004 at address 01563FCE (thread 0128), starting debugger... 0140:fixme:ver:GetCurrentPackageId (0089FECC 00000000): stub 0148:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 003c:fixme:ver:GetCurrentPackageId (0068FECC 00000000): stub
Hope this helps
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #5 from Vijay Kamuju infyquest@gmail.com --- Now the program wants get bios information using wmic. Now you got to clean up the patch and send it.
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #6 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 76111 --> https://bugs.winehq.org/attachment.cgi?id=76111 hack2 + add status to bios
Hopefully you're not getting tired of trying out patches ;), but here's same hack with a typo fixed in it, and implementation of that query in wbemprox. Same question as before:could you try it and paste console output?
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #7 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 76113 --> https://bugs.winehq.org/attachment.cgi?id=76113 possible patch
Attached a much less hacky patch.
I'm not sure but it seems like native wmic fires up a new wmic instance as in the console one can see the wmic command prompt(??)
Like this command : 'os get name' |wmic gives in the output : "wmic:cli/root>" or something like that, and then the result of the query.
Not sure how to check previous guess, but this patch more ore less tries to do the same.
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #8 from Vijay Kamuju infyquest@gmail.com --- When I try the same command on windows command line.
echo "os get name" | wmic wmic:root\cli>os get status - Alias not found. wmic:root\cli>
The above is the output on windows 10
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #9 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Vijay Kamuju from comment #8)
When I try the same command on windows command line.
echo "os get name" | wmic wmic:root\cli>os get status - Alias not found. wmic:root\cli>
The above is the output on windows 10
Hi, I tried this in windows powershell.
I think in windows cmd.exe it is passed as a whole string, so you have to leave out the double quotes:
echo os get name | wmic
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #10 from yafoce6821@giratex.com --- Only possible_patch applied
$ WINEPREFIX=~/wine/win10ltsc WINEARCH=win32 ./wine-src/wine start /d "C:\Geovision\PL9" "C:\Geovision\PL9\PL9.exe"
009c:err:sync:RtlpWaitForCriticalSection section 7BD8A2E0 "dlls/ntdll/loader.c: loader_section" wait timed out in thread 009c, blocked by 0090, retrying (60 sec) 002c:fixme:ver:GetCurrentPackageId (0066FECC 00000000): stub 0034:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 0110:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 0134:err:virtual:virtual_setup_exception stack overflow 320 bytes addr 0xffffffff stack 0x430ec0 (0x430000-0x431000-0x630000) 013c:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub wine: Unhandled page fault on read access to 00000004 at address 01563FCE (thread 012c), starting debugger... 0144:fixme:ver:GetCurrentPackageId (0089FECC 00000000): stub 014c:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 003c:fixme:ver:GetCurrentPackageId (0068FECC 00000000): stub
Only hack 2 + add status to bios applied
$ WINEPREFIX=~/wine/win10ltsc WINEARCH=win32 ./wine-src/wine start /d "C:\Geovision\PL9" "C:\Geovision\PL9\PL9.exe" 002c:fixme:ver:GetCurrentPackageId (0066FECC 00000000): stub 0034:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 0118:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 0130:fixme:wmic:wmain parsing L"bios get status" 0130:fixme:ole:CoInitializeSecurity 00000000, -1, 00000000, 00000000, 0, 3, 00000000, 0, 00000000 stub 0130:fixme:ver:GetCurrentPackageId (0062FECC 00000000): stub 0138:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub wine: Unhandled page fault on read access to 00000004 at address 01563FCE (thread 0128), starting debugger... 0140:fixme:ver:GetCurrentPackageId (0089FECC 00000000): stub 0148:fixme:ver:GetCurrentPackageId (0067FECC 00000000): stub 003c:fixme:ver:GetCurrentPackageId (0068FECC 00000000): stub
(In reply to Louis Lenders from comment #6)
Created attachment 76111 [details] hack2 + add status to bios
Hopefully you're not getting tired of trying out patches ;), but here's same hack with a typo fixed in it, and implementation of that query in wbemprox. Same question as before:could you try it and paste console output?
Not at all!
I am just so impressed how fast you pinpointed out the problem to the wmic implementation of wine. I actually lost all hope, the dll fix was easy, as I figured a stub was missing.
But honestly, if I am allowed to speak my mind, I just lost hope, in that how can anyone figure out from log files, without the actual program! But I did as I was told.
The rest of the activities is like a daily remote debugging session. No worries ;)
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #11 from Louis Lenders xerox.xerox2000x@gmail.com --- Hi,
The crash seems to be the same so this missing wmic feature is likely not the cause of the crash (nevertheless it should somehow be added)
For completeness here's last past before the crash begins. Maybe hacking around in GetLocalTime might change something (like just make it empty) but I cannot find it likely that that has a bug
010c:Call KERNEL32.GetLocalTime(0397e9b0) ret=01599c41 010c:Call ntdll.NtQuerySystemTime(0397e930) ret=7b821a3b 010c:Ret ntdll.NtQuerySystemTime() retval=00000000 ret=7b821a3b 010c:Call ntdll.RtlSystemTimeToLocalTime(0397e930,0397e938) ret=7b821a4b 010c:Ret ntdll.RtlSystemTimeToLocalTime() retval=00000000 ret=7b821a4b 010c:Call ntdll.RtlTimeToTimeFields(0397e938,0397e940) ret=7b821a65 010c:Ret ntdll.RtlTimeToTimeFields() retval=000001cb ret=7b821a65 010c:Ret KERNEL32.GetLocalTime() retval=00000004 ret=01599c41 010c:trace:seh:dispatch_exception code=c0000005 flags=0 addr=01563FCE ip=01563fce
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #12 from yafoce6821@giratex.com --- I jinxed it ;)
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #13 from yafoce6821@giratex.com --- Created attachment 76235 --> https://bugs.winehq.org/attachment.cgi?id=76235 backtrace of older PL7.exe
I do not know whether it will help, but the older version of this package (PL7.exe) spits out helpful information from the wine debugger when it crashes unlike the (PL9.exe) which has stronger obfuscation.
Motivation for sharing:
1. Obviously, to aid in finding the solution of the problem.
2. Both programs are basically the same, with few calculation fixes (bug fixes) and share a same codebase. Main difference is PL7.exe used an older Qt3 (as you can see from the dll qt-mt336.dll) and PL9 uses libstdc++ for the drawing calls.
Since, both the programs crash on startup, in exact same fashion, it is safe to assume fixing PL7.exe may fix PL9.exe also.
3. It looks like a memory addressing issue. The error message provided indicates a "page fault on read access" at memory address 0x0000046c. This typically suggests that the program attempted to access memory that it didn't have permission to access, or the memory address it attempted to access is invalid.
4. May this message also serve as a bug report that PL7.exe is also crashing on startup, in exact same manner to PL9.exe.
All the best. May the gods guide us :)
https://bugs.winehq.org/show_bug.cgi?id=56361
yafoce6821@giratex.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|9.2 |9.5
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #14 from Vijay Kamuju infyquest@gmail.com --- Fix for the first issue is now in main tree - https://source.winehq.org/git/wine.git/commitdiff/5a8bb41cad805004a8f58c1a09... I would like to close this issue, for the crash after this fix, can you open a new bug.
https://bugs.winehq.org/show_bug.cgi?id=56361
--- Comment #15 from yafoce6821@giratex.com --- (In reply to Vijay Kamuju from comment #14)
Fix for the first issue is now in main tree - https://source.winehq.org/git/wine.git/commitdiff/ 5a8bb41cad805004a8f58c1a09cdf8b1e65baf93 I would like to close this issue, for the crash after this fix, can you open a new bug.
Sure. I have opened a new bug Bug56541 for the crash after the wmic piped command fix.
You may close this issue.
https://bugs.winehq.org/show_bug.cgi?id=56361
Vijay Kamuju infyquest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |5a8bb41cad805004a8f58c1a09c | |df8b1e65baf93
--- Comment #16 from Vijay Kamuju infyquest@gmail.com --- closing as fixed
https://bugs.winehq.org/show_bug.cgi?id=56361
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 9.7.
https://bugs.winehq.org/show_bug.cgi?id=56361
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |9.0.x