https://bugs.winehq.org/show_bug.cgi?id=47668
Bug ID: 47668 Summary: System.AccessViolationException Product: Wine Version: 4.2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: johnpgoodman@gmail.com Distribution: ---
Created attachment 65111 --> https://bugs.winehq.org/attachment.cgi?id=65111 backtrace after crash
When downloading resources, Logos.exe crashes with System.AccessViolationException. This app appears to be substantially well working except for this inability to load resources which makes it useless. Many other features do work though.
https://bugs.winehq.org/show_bug.cgi?id=47668
m0rvj johnpgoodman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |logos.com
--- Comment #1 from m0rvj johnpgoodman@gmail.com --- Sorry my first bug report. I've spent hours on it trying different native dlls. It does need dotnet4.7 installed with winetricks because the app depends on wpf which is not implemented in mono.
A guide to how far we've gotten is here: https://docs.google.com/document/d/1Gms_Bc2Q_OOH3G5lmP6twXnqiSWxrFFT7lCN3nRy...
https://bugs.winehq.org/show_bug.cgi?id=47668
m0rvj johnpgoodman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |johnpgoodman@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47668
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|System.AccessViolationExcep |Logos 8 (.NET/WPF 4.7.2 |tion |application) fails to | |download resources CC| |z.figura12@gmail.com Keywords| |download URL|logos.com |https://downloads.logoscdn. | |com/LBS8/Installer/8.7.0.00 | |39/Logos-x86.msi Component|-unknown |kernelbase
--- Comment #2 from Zebediah Figura z.figura12@gmail.com --- It probably needs ReOpenFile().
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #3 from m0rvj johnpgoodman@gmail.com --- (In reply to Zebediah Figura from comment #2)
It probably needs ReOpenFile().
I'd like to try. Can you give me any tip on how? What is ReOpenFile()?
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- (In reply to m0rvj from comment #3)
(In reply to Zebediah Figura from comment #2)
It probably needs ReOpenFile().
I'd like to try. Can you give me any tip on how? What is ReOpenFile()?
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-reopenfile
I'm not immediately sure what the right thing to do is; possibly it's just to query the file name from the handle and then just open it.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #5 from m0rvj johnpgoodman@gmail.com --- (In reply to Zebediah Figura from comment #4)
(In reply to m0rvj from comment #3)
(In reply to Zebediah Figura from comment #2)
It probably needs ReOpenFile().
I'd like to try. Can you give me any tip on how? What is ReOpenFile()?
https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase- reopenfile
I'm not immediately sure what the right thing to do is; possibly it's just to query the file name from the handle and then just open it.
I see, unfortunately I don't have access to the code I'm just a user but several of us wanted to get it working on wine... I wondered if there is a dll override that could help? I've been working my way through the dependency list trying various things but most result in no change or break something. crypt32 broke login but with extra native crypt dlls it gets as far as the built in. It seems like the problem happens in the moment the encrypted file is opened. I wonder if it could be to do with character encoding?
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- (In reply to m0rvj from comment #5)
I see, unfortunately I don't have access to the code I'm just a user but several of us wanted to get it working on wine... I wondered if there is a dll override that could help?
If it's ReOpenFile(), no. It's part of kernelbase; it would need to be properly implemented on Wine.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #7 from m0rvj johnpgoodman@gmail.com --- (In reply to Zebediah Figura from comment #6)
(In reply to m0rvj from comment #5)
I see, unfortunately I don't have access to the code I'm just a user but several of us wanted to get it working on wine... I wondered if there is a dll override that could help?
If it's ReOpenFile(), no. It's part of kernelbase; it would need to be properly implemented on Wine.
Thanks that is helpful... is there a way to know for sure?
https://bugs.winehq.org/show_bug.cgi?id=47668
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox.xerox2000x@gmail.com
--- Comment #8 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 65138 --> https://bugs.winehq.org/attachment.cgi?id=65138 improve stub for ReOpenFile
(In reply to m0rvj from comment #7)
Thanks that is helpful... is there a way to know for sure?
I fixed up improved stub and for me with patch the crash does not occur anymore. @m0rvj: could you try if patch works for you? still needs lot of improvement/error checking , but maybe something along these lines could be included in Staging for now(???) if someone can confirm it works
Note: patch was generated against wine-4.10, i`ll update wine later and generate diff against latest git then and attach it.
At least problem really seems ReOpenFile;
Note: for testing in i deleted every time ~/.wine/drive_c/users/louis/Local Settings/Application Data/Logos/Data/*
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #10 from Rik Shaw rikshaw76@gmail.com ---
Note: patch was generated against wine-4.10, i`ll update wine later and generate diff against latest git then and attach it.
I am a complete NOOB at compiling WINE, but I have a test 32-bit Ubuntu 16.04 virtual machine I am using. I got the configure to complete successfully, but during make I am getting the following:
kernel32.dll-YylF9X.spec.o: In function `__wine_spec_imp_ReOpenFile': (.text+0xa37c): undefined reference to `__imp_ReOpenFile' collect2: error: ld returned 1 exit status winegcc: i686-linux-gnu-gcc failed Makefile:724: recipe for target 'kernel32.dll.so' failed make[1]: *** [kernel32.dll.so] Error 2 make[1]: Leaving directory '/home/wasta/dev/wine/wine-git/dlls/kernel32' Makefile:8343: recipe for target 'dlls/kernel32' failed make: *** [dlls/kernel32] Error 2
This is with the patch applied from @Louis so I think it may be the newer git version of wine OR I have something else wrong. Quite interested to test this patch, but am stuck on how to adjust it to comply with the newer wine code??
https://bugs.winehq.org/show_bug.cgi?id=47668
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
--- Comment #11 from Louis Lenders xerox.xerox2000x@gmail.com ---
I think it may be the newer git version of wine OR I have something else wrong.
Hi Rik, I don`t have access to my ubuntu machine atm, but the compile error is because current git is indeed too different from the git i generated the (poor) patch against. The "implementation" of ReOpenFile has moved to wine/dlls/kernelbase/file.c apparently. I could generate new patch next week. But you could also try copy /paste it (below) into wine/dlls/kernelbase/file.c (look for ReOpenFile and replace)
/*********************************************************************** * ReOpenFile (KERNEL32.@) */ HANDLE WINAPI ReOpenFile(HANDLE handle_original, DWORD access, DWORD sharing, DWORD flags) { FIXME("(%p, %d, %d, %d): stub\n", handle_original, access, sharing, flags);
WCHAR name[MAX_PATH]; DWORD size = MAX_PATH;
DWORD ret;
ret = 0; ret = GetFinalPathNameByHandleW( handle_original, name, size, VOLUME_NAME_NT ); if(ret)
FIXME("\n name is: %s\n", debugstr_w(name));
HANDLE h = CreateFileW(name, access, sharing, NULL, CREATE_ALWAYS, flags, NULL); return h; }
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #12 from Rik Shaw rikshaw76@gmail.com ---
The "implementation" of ReOpenFile has moved to wine/dlls/kernelbase/file.c apparently. I could generate new patch next week. But you could also try copy /paste it (below) into wine/dlls/kernelbase/file.c (look for ReOpenFile and replace)
Louis,
Thanks for the feedback. I didn't appreciate before that kernel32 and kernelbase were both in play. I'll look a bit more but it is giving the following complaint:
----------------- file.c: In function ‘ReOpenFile’: file.c:1269:11: warning: implicit declaration of function ‘GetFinalPathNameByHandleW’ [-Wimplicit-function-declaration] ret = GetFinalPathNameByHandleW( handle_original, name, size, VOLUME_NAME_N ^ file.c: In function ‘ReadDirectoryChangesW’: file.c:1311:70: error: ‘invoke_completion’ undeclared (first use in this function) completion && overlapped ? invoke_comp ^ file.c:1311:70: note: each undeclared identifier is reported only once for each function it appears in Makefile:222: recipe for target 'file.cross.o' failed -----------------
I think it is related to GetFinalPathNameByHandleW not being in the kernelbase/file.c but only in the kernel32/file.c. So I am not sure if I need to either reference the kernel32/file.c or if I need to duplicate the code over to kernelbase/file.c. Once again this is the first time involved at all in anything related to the wine source code so forgive my ignorance :-)
One other minor note is that I had to move the declarations to the top of the block since it was complaining that declarations and code shouldn't be mixed. So I separately declare HANDLE h; at the top, for instance.
Wow I still can't believe we may be *close* to running Logos in wine. This has been a 4+ year debugging endeavor that will have huge benefits if it can happen.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #13 from Rik Shaw rikshaw76@gmail.com --- Well actually there is only a warning about GetFinalPathNameByHandleW not being declared. If I copy in the code from the kernel32/file.c, then it warns about other functions not being declared (strncmpiW, strlenW, strcatW). strlenW should be lstrlenW, so that one was easy. But the other two I don't know about.
Regardless, those are the warnings but the **error** comes from the **invoke_completion** not being declared. This is from the ReadDirectoryChangesW function, which I am not touching?? So still confused... here is the line with "invoke_completion" in it:
---------------------------------- status = NtNotifyChangeDirectoryFile( handle, completion && overlapped ? NULL : pov->hEvent, completion && overlapped ? invoke_completion : NULL, cvalue, ios, buffer, len, filter, subtree ); ----------------------------------
So I should probably re-base on wine 4.10 so I can test your patch as it stood before, then we go forward with updating it for current git code. Otherwise we are chasing our tails. Thanks again for the efforts so far...
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #14 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 65247 --> https://bugs.winehq.org/attachment.cgi?id=65247 poor patch
Hi Rik, this poor patch should apply against current git ( wine-16). Could try the patch and see if it improves things?
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #15 from Rik Shaw rikshaw76@gmail.com --- Louis,
Thanks for the updated patch: it helps me see how to reference the external function.
I am now able to "make" wine from git with the patch applied, and then install Logos8 (first installing the dotnet472 winetrick). Unfortunately Logos8 is crashing for me just after the splash screen. I am trying to get a newer Logos8 version downloaded (I had a bit older one) and after I have it and can do a bit cleaner testing I'll try to report back.
Rik
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #16 from Rik Shaw rikshaw76@gmail.com --- Created attachment 65249 --> https://bugs.winehq.org/attachment.cgi?id=65249 Initial Backtrace
Initial backtrace after launching Logos 8 with patch
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #17 from Rik Shaw rikshaw76@gmail.com --- Created attachment 65250 --> https://bugs.winehq.org/attachment.cgi?id=65250 Secondary Backtrace
This crash now comes each time attempting to launch Logos8.exe
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #18 from Rik Shaw rikshaw76@gmail.com --- Again forgive the ignorance but I am now getting the crash per the "Secondary Backtrace" attachment. It is referring to wined3d errors so I wonder if I need to install one of those winetricks? Any advice on which one(s)?
Thanks for the help in attempting to confirm the fix! You guys deserve a "patience" award!
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #19 from Rik Shaw rikshaw76@gmail.com --- Created attachment 65251 --> https://bugs.winehq.org/attachment.cgi?id=65251 Terminal Output from Crash
The terminal output is also referencing many d3d errors so it seems I am needing to apply some winetrick or other to address these issues.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #20 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Rik Shaw from comment #19)
Created attachment 65251 [details] Terminal Output from Crash
Did you already try "winetricks d3dcompiler_47" ??
Also, make sure you run from directory where Logos.exe is present:
cd ~/wine-logos8/drive_c/users/wasta/Local\ Settings/Application\ Data/Logos/
(or where-ever the the directory is present);
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #21 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 65252 --> https://bugs.winehq.org/attachment.cgi?id=65252 console output from running Logos
Just for reference to compare i attach my console output, up to the point where the application comes up.
@Rik: I noticed this in your console output:
0031:fixme:d3d:wined3d_guess_gl_vendor Received unrecognized GL_VENDOR "Humper". Returning GL_VENDOR_UNKNOWN. 0031:fixme:d3d:wined3d_guess_card_vendor Received unrecognized GL_VENDOR "Humper". Returning HW_VENDOR_NVIDIA. 0031:fixme:d3d:select_card_handler Couldn't find a suitable card selector for GL vendor 0000 (using GL_RENDERER "Chromium")
What graphics card do you have, or is it run in Virtualbox?
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #22 from Rik Shaw rikshaw76@gmail.com --- Thanks for the tip on graphics: indeed I have been running in Virtualbox. I *disabled* 3D graphics in VBox Settings, and now Logos is able to launch! It is very "glitchy" with screen artifacts not going away, but so far it has *not* crashed. It is in the middle of downloading resources which will need to run overnight. But I tried manually putting Logos 7 resources in place and it was then crashing, so starting with clean resource downloads.
So not sure if you have any advice on what is needed or why 3D graphics would be crashing Logos but I can live with this for testing. I will have to report back in the morning after resource downloads are completed to confirm, but it is looking good!
BTW there are 1000's of these running by....
0040:fixme:crypt:SystemFunction040 (0x10d4e2dc, 50, 0): stub [RtlEncryptMemory] 0040:fixme:crypt:SystemFunction041 (0x10d4e274, 50, 0): stub [RtlDecryptMemory]
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #23 from Rik Shaw rikshaw76@gmail.com --- I have now setup a dedicated 32bit Ubuntu 18.04 machine for building and testing. Note that when I built this time I was able to source a vkd3d-dev package from ppa that possibly may address the d3d errors I was getting when running with 3D graphics under virtualbox. You can find the package here: https://launchpad.net/~cybermax-dexter/+archive/ubuntu/vkd3d
Regardless, now that I am testing on "real hardware" I don't have those issues.
However, I still think there is an issue with downloading resources. There is no crash anymore (yay!) but the resources seem to pile up / get stuck in the Logos/<random id>/ResourceManager/Downloaded folder. This folder is now several GB in size with a subfolder for each resource in it. And Logos is still reporting that "no resources are installed", with spinning circles next to each resource. I left this running overnight with no improvement. I deleted and re-started from scratch, and see this for each resource as it is being downloaded:
01f0:fixme:file:ReOpenFile (00000974, -2147483648, 1, 0): stub 01f0:fixme:file:ReOpenFile name is: L"\Device\HarddiskVolume1\users\wasta\Local Settings\Application Data\Logos\Data\npvcol5h.hgw\ResourceManager\Downloaded\LLS_KJV1900\KJV1900.logos4" 01f0:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
Here is another one:
01bb:fixme:file:ReOpenFile (00000690, -2147483648, 1, 0): stub 01bb:fixme:file:ReOpenFile name is: L"\Device\HarddiskVolume1\users\wasta\Local Settings\Application Data\Logos\Data\npvcol5h.hgw\ResourceManager\Downloaded\LLS_KJV1900\KJV1900.logos4" 01bb:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet
So in summary, I think the "ThreadIsIoPending" not being supported yet is the place of the problem.
To compare / contrast to a W10 install, I have a 32bit W10 install with Logos8 installed that I am running now to test. For it, the resources do get *temporarily* downloaded to the Logos/<random id>/ResourceManager/Downloaded folder, but then they are moved from there to the various ResourceManager sub-folders after the downloads are finished and verified (??).
Can anyone else confirm that Logos8 with Wine is still not getting Resources downloaded to the point of being found by Logos and they are getting *stuck* in the "Downloaded" folder?
Any advice on the possible issue of the "ThreadIsIoPending" not being implemented?
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #24 from Rik Shaw rikshaw76@gmail.com --- I see here that the NTQueryInformationThread ThreadIoIsPending class should instead use the GetThreadIOPendingFlag function:
https://stackoverflow.com/questions/44615400/why-we-need-to-check-the-isiope...
I am guessing (??) that Logos is using it to determine if the download is completed or not. Since it never returns, then Logos doesn't know the download is done (??). Not sure if there is a Wine way to address this, or if this is where we need to go back to Logos developers...
https://bugs.winehq.org/show_bug.cgi?id=47668
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #25 from Fabian Maurer dark.shadow4@web.de ---
Not sure if there is a Wine way to address this, or if this is where we need to go back to Logos developers...
If it works on windows, it should work on wine as well.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #26 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Rik Shaw from comment #23)
So in summary, I think the "ThreadIsIoPending" not being supported yet is the place of the problem.
It could also be (more likely i think) my poor patch is just not correct/good enough. To get some useful info could you try run with
WINEDEBUG=+relay,+file wine Logos.exe &>log.txt
and attach (bzipped2) file log.txt to this bugreport? Maybe it might shed a light on the cause, and developers could also have a look at it. (note; make sure to not ctrl`c the program before at least one resource is downloaded)
Regards
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #27 from Zebediah Figura z.figura12@gmail.com --- (In reply to Rik Shaw from comment #24)
I see here that the NTQueryInformationThread ThreadIoIsPending class should instead use the GetThreadIOPendingFlag function:
https://stackoverflow.com/questions/44615400/why-we-need-to-check-the- isiopending-when-the-worker-thread-going-to-exit
Well, no. GetThreadIOPendingFlag() is implemented on top of NtQueryInformationThread(ThreadIsIoPending).
I am guessing (??) that Logos is using it to determine if the download is completed or not. Since it never returns, then Logos doesn't know the download is done (??). Not sure if there is a Wine way to address this, or if this is where we need to go back to Logos developers...
Probably not, for two reasons: firstly, it does return; it just always returns FALSE; secondly, that specific FIXME message is pretty common across a wide range of programs and doesn't indicate a cause of failure.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #28 from Rik Shaw rikshaw76@gmail.com ---
To get some useful info could you try run with
WINEDEBUG=+relay,+file wine Logos.exe &>log.txt
and attach (bzipped2) file log.txt to this bugreport?
Wow that log file adds up quickly! It quickly jumped to many 100's of MB!!! But I think I saw enough output flash by to show the resources it was trying to download complete and move to other resources. I was watching the console by using "tee -a" for the log file. Compressed it is down to 22MB but uncompressed it is 919MB in size!!
What can I do to read the file, btw? Using "nano" it takes forever to load. I recall there may be some alt text editor that will not attempt to load the full file into memory in order to read only a portion of it.
Anyway, hopefully there is something useful for someone in the file to understand better what is needed.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #29 from Rik Shaw rikshaw76@gmail.com --- Since the attachment size is 10MB I uploaded the 22MB log file here: https://drive.google.com/file/d/1jucK1yeki9AC0YFoZbPTvPnwTzPvOtSj/view?usp=s...
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #30 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 65284 --> https://bugs.winehq.org/attachment.cgi?id=65284 patch slightly modified
Hi Rik,
Could you try if the attached modified patch changes anything?
I don`t have access to various resources, but i just deleted the whole folder ~/.wine/drive_c/users/louis/Local Settings/Application Data/Logos/Data/<resource-id> and while the folder ~/.wineremote/drive_c/users/louis/Local Settings/Application Data/Logos/Data/<resource-id>/ResourceManager/Resources stays empty with previous patch, it does seems to get populated with a few files with the modified patch (for example Logos-Help).
Maybe it could help a bit, maybe it doesn`t but worth a try?
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #31 from Rik Shaw rikshaw76@gmail.com ---
Could you try if the attached modified patch changes anything?
Maybe it could help a bit, maybe it doesn`t but worth a try?
@Louis: you, sir, are BRILLIANT!
I can confirm with the first few resources that they are getting downloaded to the ResourceManager\Downloaded folder, then after completing they are being moved out of Downloaded and into the ResourceManager\Resources folder. When I look in the "Library" they show as being "On This Device."
I will let it keep downloading over night again and report back, but am assuming all the resources will now be available.
Later I will need to work out how to distribute this patched wine locally to colleagues here in Ethiopia, and maybe address some of the visual glitches such as the "black windows" that show up often with wine. But these are minor compared to the major hurdle of resources actually being available!!!
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #32 from Rik Shaw rikshaw76@gmail.com ---
I will let it keep downloading over night again and report back, but am assuming all the resources will now be available.
Later I will need to work out how to distribute this patched wine locally to colleagues here in Ethiopia, and maybe address some of the visual glitches such as the "black windows" that show up often with wine. But these are minor compared to the major hurdle of resources actually being available!!!
Thanks again to @Louis for the patch. It seems that things are working well with Logos Resources now. How is the best way to get this incorporated and available to others?
https://bugs.winehq.org/show_bug.cgi?id=47668
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #33 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Rik Shaw from comment #32)
It seems that things are working well with Logos Resources now. How is the best way to get this incorporated and available to others?
Hi Rik, hopefully one of the developers could step in.
Basically some tests need to be written to find correct semi-stub (I just did some trial and error changing CREATE_ALWAYS into OPEN_EXISTING and that seemed to work) Getting patch in is rather time consuming, and I don't have that time atm, sorry
So if someone could pick this up (hint at Staging guys ;) ) that would be great
Regards
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #34 from Rik Shaw rikshaw76@gmail.com ---
Getting patch in is rather time consuming, and I don't have that time atm, sorry
So if someone could pick this up (hint at Staging guys ;) ) that would be great
@Louis, understood that you aren't able to take this any farther. Thanks again for your time already in providing the patch. Is it appropriate to change the status from "NEW" since there is now a patch awaiting possible cleanup and integration? Just wondering how to best indicate that it is ready for that level to developers that may not be watching this thread?
Thanks again
https://bugs.winehq.org/show_bug.cgi?id=47668
Louis Lenders xerox.xerox2000x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Logos 8 (.NET/WPF 4.7.2 |Logos 8 (.NET/WPF 4.7.2 |application) fails to |application) fails to |download resources |download resources (needs | |ReOpenFile implemantation)
--- Comment #35 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to Rik Shaw from comment #34) Is it appropriate to
change the status from "NEW" since there is now a patch
Setting status to confirmed, + updated title
Note, if you'd like other users to test meanwhile before this is fixed i think there's a way (not very preferable but i think i remember it worked when i tried this in the past, not sure if it still works):
If you copy your self-compiled (with patch) kernelbase.dll.so over the fakedlls in systemdirectories (64-bit over .wine/windows/system32/kernelbase.dll and 32-bit over .wine/windows/syswow64/kernelbase.dll) and then set kernelbase to native in winecfg one should be able to run the app in wine-3.16 without a patched wine, but just vanilla wine-3.16 )
As i said not sure if it (still) works, but if so, you'd only need to give them the self-compiled kernelbase.dll.so's, and then they could use vanilla wine-3.16
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #36 from m0rvj johnpgoodman@gmail.com --- I can confirm the patch works for 64bit too. I have it fully working on kubuntu 19.04 following Rik's instructions but just swapping 32 to 64 each time. N.b. the patch would not apply automatically. I had to cut and paste the text directly.
https://bugs.winehq.org/show_bug.cgi?id=47668
m0rvj johnpgoodman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|4.2 |4.16 Hardware|x86 |x86-64
--- Comment #37 from m0rvj johnpgoodman@gmail.com --- Updated wine version to 4.16 and arch to x64 although it applies to both 32 and 64bit builds.
Working patch all this needs is someone with the expertise to get the patch merged in? Anyone able to help? Many thanks!
https://bugs.winehq.org/show_bug.cgi?id=47668
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|4.16 |4.2
--- Comment #38 from Fabian Maurer dark.shadow4@web.de --- Please don't change the reported version.
https://bugs.winehq.org/show_bug.cgi?id=47668
Don Pobanz dpobanz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dpobanz@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #39 from Don Pobanz dpobanz@gmail.com --- I tried to manually apply the patch with the newest wine from git today (wine-4.17-44-gceabad19b8) but it doesn't appear to help.
I am modifying dlls/kernelbase/file.c and adding the following line at line 46:
extern DWORD WINAPI GetFinalPathNameByHandleW( HANDLE ,LPWSTR ,DWORD , DWORD);
I then jump down to line 1825 and remove the line return INVALID_HANDLE_VALUE;
and add in its place these lines:
WCHAR name[MAX_PATH]; DWORD size = MAX_PATH; HANDLE h; DWORD ret;
ret = 0; ret = GetFinalPathNameByHandleW( handle, name, size, VOLUME_NAME_DOS ); if(ret) FIXME("\n name is: %s\n", debugstr_w(name)); else return INVALID_HANDLE_VALUE;
h = CreateFileW(name, access, sharing, NULL, OPEN_EXISTING, flags, NULL);
return h;
When compiling I get a warning but it appears to compiles: file.c:1827:5: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] WCHAR name[MAX_PATH]; ^~~~~ The Logos8.msi installs fine
When I try and run it cd ~/.wine/drive_c/users/don wine
wine 4.17.44
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #40 from Don Pobanz dpobanz@gmail.com --- The patch works for me. Even if it is not in the final form, progress is being made.
I manually applied the 'patch slightly modified' of Louis Lenders from 2019-09-23 with the newest wine from git today (wine-4.17-44-gceabad19b8) and it works for me. When I run Logos 8, it asks me for my login information and is now downloading my library. $ cd ~/.wine/drive_c/users/don/Local\ Settings/Application\ Data/Logos/ $ wine Logos.exe
This is very exciting since it was about 10 years ago that I began experimenting with using Logos through wine. There have been several Logos versions released since then, but this is the first time that any of them worked even partially.
Thanks so much to those of you working on this including Rik Shaw, m0rvj, Louis Lenders, Zebediah Figura.
Linux Mint 19.1, Cinnamon edition, 32 bit
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #41 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 65380 --> https://bugs.winehq.org/attachment.cgi?id=65380 tests + patch
I had some spare hours and wrote some simple tests for ReopenFile and improved stub a bit.
See attachment
Tests pass on test bot with the patch.
Request @Alsitair and/or Zebediah: Is this good enough to include in Staging?
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #42 from Zebediah Figura z.figura12@gmail.com --- (In reply to Louis Lenders from comment #41)
Request @Alsitair and/or Zebediah: Is this good enough to include in Staging?
It seems safe enough for Staging, and not obviously wrong, but why stop at Staging?
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #43 from Louis Lenders xerox.xerox2000x@gmail.com ---
It seems safe enough for Staging, and not obviously wrong, but why stop at Staging?
Well, I haven`t had much luck with getting patches in with more than 5 lines of code (unless they were signed off by others) so I kind of gave up to send patches in apart from simple stubs etc. I think if patch can be upstreamed from Staging there`s a better chance to get something in
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #44 from m0rvj johnpgoodman@gmail.com --- Louis Lenders thanks for this! How's it going getting it into staging?
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #45 from m0rvj johnpgoodman@gmail.com --- We have a growing user base and can confirm that this appears to be stable. I'm unsure of the system but I'd love to see this patch get accepted into wine... Louis, you've taken us so far! Thanks so much! Is there anything we can do to help you get it included?
https://bugs.winehq.org/show_bug.cgi?id=47668
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |leslie_alistair@hotmail.com Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/kernelbase-ReOpe | |nFile Status|NEW |STAGED
https://bugs.winehq.org/show_bug.cgi?id=47668
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Logos 8 (.NET/WPF 4.7.2 |Logos 8 (.NET/WPF 4.7.2 |application) fails to |application) fails to |download resources (needs |download resources (needs |ReOpenFile implemantation) |ReOpenFile implementation)
https://bugs.winehq.org/show_bug.cgi?id=47668
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #46 from Anastasius Focht focht@gmx.net --- Hello folks,
adding another app: Verbum 8 (Catholic Study Software). It is based on the same Logos Bible library/code (https://www.logos.com/).
Download: https://verbum.com/downloads/282
--- snip --- $ pwd /home/focht/.wine/drive_c/users/focht/Local Settings/Application Data/Verbum/System
$ find . -iname "*.exe" ./LogosCEF.exe ./Verbum.exe ./VerbumIndexer.exe ./LogosCom.exe ./LogosUpdater.exe
$ wine64 ./Verbum.exe >>log.txt 2>&1 ... 0047:fixme:file:ReOpenFile (0000000000000B5C, 1073741824, 2, 0): stub 0047:fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (000000003571A0C0 1 C) semi-stub 0047:fixme:msvcp:_Locinfo__Locinfo_ctor_cat_cstr (0000000035719D10 1 C) semi-stub 0047:fixme:advapi:RegisterEventSourceW ((null),L".NET Runtime"): stub 0047:fixme:advapi:ReportEventW (0xcafe4242,0x0001,0x0000,0x00000402,(nil),0x0001,0x00000000,0x3571c000,(nil)): stub 0047:err:eventlog:ReportEventW L"Application: Verbum.exe\nFramework Version: v4.0.30319\nDescription: The process was terminated due to an unhandled exception.\nException Info: System.AccessViolationException\n at Libronix.DigitalLibrary.NativeMethods.PatchResource(Libronix.DigitalLibrary.SafeILicenseManagerHandle, Sys"... 0047:fixme:advapi:DeregisterEventSource (0xcafe4242) stub
Unhandled Exception: 0047:fixme:ver:GetCurrentPackageId (0x35719c90 (nil)): stub System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. at Libronix.DigitalLibrary.NativeMethods.PatchResource(SafeILicenseManagerHandle pLicenseManager, String strSourcePath, String strPatchPath, String strOutputPath) at LDLS4.Update.InstallResourceUpdateStage.TryApplyResourcePatch(DownloadJob downloadJob, String resourceInstallPath, String oldResourcePath) at LDLS4.Update.InstallResourceUpdateStage.ProcessFinishedResourcePatch(DownloadableUpdateJob updateJob, DownloadJob downloadJob, String resourceInstallPath, IWorkState workState) at LDLS4.Update.InstallResourceUpdateStage.ProcessDownloadableUpdateJob(DownloadableUpdateJob updateJob, DownloadJob downloadJob, IWorkState workState) at LDLS4.Update.InstallResourceUpdateStage.DoWorkCore(IWorkState workState) at LDLS4.Update.UpdateStageBase.<DoWork>d__23.MoveNext() at Libronix.Utility.Threading.AsyncWorkerTask`1.EnumMoveNext() at Libronix.Utility.Threading.AsyncWorkerTask`1.ContinueExecution(Object unused) at Libronix.Utility.Threading.GroupedThreadPool.ExecuteNextCallback(Object state) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx) at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem() at System.Threading.ThreadPoolWorkQueue.Dispatch() wine: Unhandled page fault on read access to 0000000000000000 at address 00000000201380E5 (thread 0047), starting debugger... --- snip ---
Tidbit: The explicit 'wine64' is needed because some .NET executables are 'anycpu' hence will be executed as Wow64 process in Wine by default (PE32 sig). This is only needed if the bootstrapper/launcher process is skipped (parent folder) which ensures 64-bit child process creation.
Relevant part of trace log:
--- snip --- $ WINEDEBUG=+seh,+relay wine64 ./Verbum.exe >>log.txt 2>&1 ... 0033:Call KERNEL32.LoadLibraryExW(034ed730 L"C:\users\focht\Local Settings\Application Data\Verbum\System\Libronix.DigitalLibrary.Native.dll",00000000,00000008) ret=02681794 ... 0033:Ret KERNEL32.LoadLibraryExW() retval=1fee0000 ret=02681794 ... 0060:Call PE DLL (proc=0x201dd0b8,module=0x1fee0000 L"Libronix.DigitalLibrary.Native.",reason=THREAD_ATTACH,res=(nil)) 0060:Ret PE DLL (proc=0x201dd0b8,module=0x1fee0000 L"Libronix.DigitalLibrary.Native.",reason=THREAD_ATTACH,res=(nil)) retval=1 ... 0060:Call KERNEL32.GetProcAddress(1fee0000,1d26026b "PatchResource") ret=0273fc00 0060:Ret KERNEL32.GetProcAddress() retval=1ff07ec0 ret=0273fc00 ... 0060:Call KERNEL32.CreateFileW(339c99a0 L"C:\users\focht\Local Settings\Application Data\Verbum\Data\0w52orzh.cex\UpdateManager\Resources\287\UAV.lbsuav",40000000,00000002,00000000,00000002,00000080,00000000) ret=201427bb ... 0060:Ret KERNEL32.CreateFileW() retval=00000ab4 ret=201427bb ... 0060:Call KERNEL32.ReOpenFile(00000ab4,40000000,00000002,00000000) ret=2014221c 0060:fixme:file:ReOpenFile (0000000000000AB4, 1073741824, 2, 0): stub 0060:Ret KERNEL32.ReOpenFile() retval=ffffffffffffffff ret=2014221c 0060:Call KERNEL32.GetLastError() ret=20142452 0060:Ret KERNEL32.GetLastError() retval=00000000 ret=20142452 0060:Call KERNEL32.FormatMessageA(00001100,00000000,00000000,00000400,2d72da40,00000000,00000000) ret=2010cee4 ... 0060:Ret KERNEL32.FormatMessageA() retval=0000000a ret=2010cee4 0060:Call KERNEL32.lstrlenA(035d52f0 "Success.\r\n") ret=2010cef3 0060:Call ntdll.strlen(035d52f0 "Success.\r\n") ret=71095954 0060:Ret ntdll.strlen() retval=0000000a ret=71095954 0060:Ret KERNEL32.lstrlenA() retval=0000000a ret=2010cef3 ... 0060:Call ucrtbase.__stdio_common_vsnprintf_s(00000004,2d72c9c0,00001000,ffffffffffffffff,202746c0 "Issuing exception 0x%08X: %s [%hs(%d)]",00000000,2d72da18) ret=201047f2 0060:Ret ucrtbase.__stdio_common_vsnprintf_s() retval=0000008a ret=201047f2 ... 0060:Call ucrtbase._CxxThrowException(2d72da90,2034fe40) ret=201de877 0060:Call ntdll.RtlPcToFileHeader(2034fe40,2d72d9d8) ret=7fc4209c9ab5 0060:Ret ntdll.RtlPcToFileHeader() retval=1fee0000 ret=7fc4209c9ab5 0060:Call KERNEL32.RaiseException(e06d7363,00000001,00000004,2d72d9c0) ret=7fc4209c9acd 0060:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7104f93d ip=7104f93d tid=0060 0060:trace:seh:raise_exception info[0]=0000000019930520 0060:trace:seh:raise_exception info[1]=000000002d72da90 0060:trace:seh:raise_exception info[2]=000000002034fe40 0060:trace:seh:raise_exception info[3]=000000001fee0000 0060:trace:seh:raise_exception rax=000000002d72d870 rbx=000000002d72d9c0 rcx=000000002d72d870 rdx=000000002d72d890 0060:trace:seh:raise_exception rsi=000000002d72d9e0 rdi=000000002d72d8b0 rbp=000000002d72d988 rsp=000000002d72d850 0060:trace:seh:raise_exception r8=0000000000000004 r9=000000002d72d9c0 r10=0000000000000000 r11=0000000000000000 0060:trace:seh:raise_exception r12=0000000005a07a7c r13=000000002d72e190 r14=000000002d72dbe0 r15=0000000000000000 0060:trace:seh:call_vectored_handlers calling handler at 0x2669250 code=e06d7363 flags=1 ... 0060:Call KERNEL32.FormatMessageA(00001300,00000000,00000000,00000400,2d72daa8,00000000,00000000) ret=2010d59a ... 0060:Ret KERNEL32.FormatMessageA() retval=0000000a ret=2010d59a ... 0060:Call msvcp140.?xsputn@?$basic_streambuf@DU?$char_traits@D@std@@@std@@MEAA_JPEBD_J@Z(2d72a028,20274818 "Exception 0x",0000000c) ret=7bca1bff ... 0060:Call ucrtbase.__uncaught_exception() ret=66a9a615 0060:Ret ucrtbase.__uncaught_exception() retval=00000000 ret=66a9a615 ... 0060:Call msvcp140.?xsputn@?$basic_streambuf@DU?$char_traits@D@std@@@std@@MEAA_JPEBD_J@Z(2d72a028,2027aca0 "b:\jenkins\workspace\logos-desktop-win-stable\sinai\src\sinairesource\comutil\filestream.cpp",0000005c) ret=7bca1bff ... 0060:trace:seh:RtlRestoreContext returning to 20142337 stack 2d72dac0 ... 0060:Call ucrtbase.malloc(00000040) ret=20155c43 0060:Call ntdll.RtlAllocateHeap(1fdd0000,00000000,00000040) ret=7fc4209eeb75 0060:Ret ntdll.RtlAllocateHeap() retval=339c9c90 ret=7fc4209eeb75 0060:Ret ucrtbase.malloc() retval=339c9c90 ret=20155c43 0060:Call ucrtbase.strcmp(2027ce18 "IV",202848f8 "ValueNames") ret=201b068f 0060:Ret ucrtbase.strcmp() retval=ffffffff ret=201b068f 0060:Call ucrtbase.__std_type_info_compare(2035d4d0,2035d2f8) ret=2014cc8e 0060:Ret ucrtbase.__std_type_info_compare() retval=ffffffff ret=2014cc8e 0060:Call ucrtbase.__std_type_info_compare(2035d4d0,2035d4d0) ret=20130b3c 0060:Ret ucrtbase.__std_type_info_compare() retval=00000000 ret=20130b3c 0060:Call ucrtbase.free(00000000) ret=2014e0af 0060:Call KERNEL32.HeapFree(1fdd0000,00000000,00000000) ret=7fc4209eeb95 0060:Ret KERNEL32.HeapFree() retval=00000001 ret=7fc4209eeb95 0060:Ret ucrtbase.free() retval=00000001 ret=2014e0af 0060:trace:seh:raise_exception code=c0000005 flags=0 addr=0x201580e5 ip=201580e5 tid=0060 0060:trace:seh:raise_exception info[0]=0000000000000000 0060:trace:seh:raise_exception info[1]=0000000000000000 0060:trace:seh:raise_exception rax=00000000339c9730 rbx=0000000000000000 rcx=0000000000000000 rdx=0000000000000000 0060:trace:seh:raise_exception rsi=000000002d72db10 rdi=0000000000000000 rbp=000000002d72db29 rsp=000000002d72da70 0060:trace:seh:raise_exception r8=000000002d72dea0 r9=0000000000000008 r10=000000002027e040 r11=0000000000000000 0060:trace:seh:raise_exception r12=0000000000000001 r13=0000000000000008 r14=00000000339c96e0 r15=00000000339b8cb0 0060:trace:seh:call_vectored_handlers calling handler at 0x2669250 code=c0000005 flags=0 --- snip ---
Main assembly info:
--- snip --- [assembly: InternalsVisibleTo("LDLS4.IntegrationTests")] [assembly: AssemblyTitle("Verbum")] [assembly: RuntimeCompatibility(WrapNonExceptionThrows = true)] [assembly: TargetFramework(".NETFramework,Version=v4.7.2", FrameworkDisplayName = ".NET Framework 4.7.2")] [assembly: ComVisible(false)] [assembly: AssemblyTrademark("")] [assembly: Guid("81490292-5570-4D02-A2AC-7B828DBD0A8A")] [assembly: InternalsVisibleTo("LDLS4.Tests")] [assembly: AssemblyProduct("Verbum")] [assembly: CompilationRelaxations(8)] [assembly: NeutralResourcesLanguage("en-US")] [assembly: AssemblyCompany("Faithlife Corporation")] [assembly: ThemeInfo(ResourceDictionaryLocation.None, ResourceDictionaryLocation.SourceAssembly)] [assembly: InternalsVisibleTo("Logos4.DynamicExecution")] [assembly: AssemblyConfiguration("Ship")] [assembly: AssemblyDescription("8.10 SR-1")] [assembly: Extension] [assembly: AssemblyAssociatedContentFile("vorbis.acm")] [assembly: AssemblyCopyright("Copyright 2009-2019 Faithlife Corporation")] [assembly: AssemblyVersion("8.10.0.32")] --- snip ---
$ sha1sum VerbumSetup.exe 58f591f43e8cb7b2727d74b9fbaff0ddd8ff4d3e VerbumSetup.exe
$ du -sh VerbumSetup.exe 536K VerbumSetup.exe
Full setup from bootstrapper download:
$ sha1sum verbum/Install/Installers/Verbum-x64.msi 33b00bfdf8687fdd28cc71aeede16746014e6d3e verbum/Install/Installers/Verbum-x64.msi
$ du -sh verbum/Install/Installers/Verbum-x64.msi 187M verbum/Install/Installers/Verbum-x64.msi
$ wine --version wine-5.0-rc3
Regards
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #47 from Anastasius Focht focht@gmx.net --- *** Bug 48333 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=47668
Nick nick.andrewes@phonecoop.coop changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nick.andrewes@phonecoop.coo | |p
--- Comment #48 from Nick nick.andrewes@phonecoop.coop --- Created attachment 66170 --> https://bugs.winehq.org/attachment.cgi?id=66170 Backtrace from Indexing Error
The indexer crashed under: wine-staging-5-rc3 winxp 64 bit Debian Bullseye
This is the backtrace.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #49 from Nick nick.andrewes@phonecoop.coop --- Created attachment 66171 --> https://bugs.winehq.org/attachment.cgi?id=66171 Terminal Output from Indexing Error
The indexer crashed under: wine-staging-5-rc3 winxp 64 bit Debian Bullseye
This is the terminal output.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #50 from m0rvj johnpgoodman@gmail.com --- That's the same as the error I was seeing.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #51 from m0rvj johnpgoodman@gmail.com --- It would appear from user reports that the LogosIndexer.exe will only complete if winecfg has set the indexer to run with winxp as the win version. Logos.exe needs to be set as win7.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #52 from Louis Lenders xerox.xerox2000x@gmail.com --- (In reply to m0rvj from comment #51)
It would appear from user reports that the LogosIndexer.exe will only complete if winecfg has set the indexer to run with winxp as the win version. Logos.exe needs to be set as win7.
Is this reproducable e.g. does it crash every time at the same point? If so, could you attach a WINEDEBUG=+relay,+seh,+file debug log (bzipped2)? Regards
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #53 from Nick nick.andrewes@phonecoop.coop --- Created attachment 66237 --> https://bugs.winehq.org/attachment.cgi?id=66237 Backtrace from indexing Error: wine-staging-5-rc5
Thanks for the reply.
I've now tested under wine-staging_5_rc5 on Debian Bullseye (=Testing) 64 bit, by running these commands from a standard 64bit bottle as per the application page. I found that the Indexer was automatically starting during the first run of Logos.exe:
WINEPREFIX=$HOME/wine-logos-64bit-5rc5/ msiexec /i Logos-x64.msi
WINEPREFIX=~/wine-logos-64bit-5rc5/ winecfg ~/wine-logos-64bit-5rc5/
(At this point I set Logos to win7; and Default to xp. There was no LogosIndexer.exe to manually select). It might be worth checking to see if the applications fired correctly.
WINEPREFIX=$HOME/wine-logos-64bit-5rc5/ WINEDEBUG=+relay,+seh,+file wine64 ~/wine-logos-64bit-5rc5/drive_c/users/nick/Local\ Settings/Application\ Data/Logos/Logos.exe
I will try to upload the debug log, however, I suspect that even with bzip2, it might be too big to upload. Unzipped it's 4.5Gb.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #54 from Nick nick.andrewes@phonecoop.coop --- Debug Log from indexing Error: wine-staging-5-rc5
Thanks for the reply.
I've now tested under wine-staging_5_rc5 on Debian Bullseye (=Testing) 64 bit, by running these commands from a standard 64bit bottle as per the application page. I found that the Indexer was automatically starting during the first run of Logos.exe:
WINEPREFIX=$HOME/wine-logos-64bit-5rc5/ msiexec /i Logos-x64.msi
WINEPREFIX=~/wine-logos-64bit-5rc5/ winecfg ~/wine-logos-64bit-5rc5/
(At this point I set Logos to win7; and Default to xp. There was no LogosIndexer.exe to manually select). It might be worth checking to see if the applications fired correctly.
WINEPREFIX=$HOME/wine-logos-64bit-5rc5/ WINEDEBUG=+relay,+seh,+file wine64 ~/wine-logos-64bit-5rc5/drive_c/users/nick/Local\ Settings/Application\ Data/Logos/Logos.exe
You can find the debug log at https://bit.ly/380U3u8
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #55 from Louis Lenders xerox.xerox2000x@gmail.com --- Created attachment 66244 --> https://bugs.winehq.org/attachment.cgi?id=66244 last 4000 lines before reference of "Unhandled exception"
Hi the log is really huge so quite difficult to find needles i guess...
I attach last 4000 lines of your log before a suspicious "Unhandled exception" is referenced. Not 100% sure if this is useful part.
However: to make a useful debuglog I`d say set version to win7, and don`t change anything. As far as i understand from the comments the error for LogosIndexer only occured in win7 and not in winxp, right? Then it suprises me you get a crash now in winxp: Quote: "At this point I set Logos to win7; and Default to xp. There was no LogosIndexer.exe to manually select".
Anyway, if it`s not too much trouble attaching a debuglog with win7 default (for all apps).
In your whole debuglog is not a single call to ReopenFile. This is probably due to the fact that version is set to winxp...
Last remark: This is very likely a red herring but to exclude it from being the cause of trouble: just before the "Unhandled exception" reference there`s a call to DwmIsCompositionEnabled. As the crash only seems to happen in win7 and not in winxp it might be interesting to see what happens if you apply the hack from https://bugs.winehq.org/attachment.cgi?id=62551&action=diff&context=...
Another simple thing to try that just jumps in mind: Set version to winvista and see what happens (ReOpenFile seems to be introduced in vista, so if it crashes then it might still be related to ReOpenFile)
regards
https://bugs.winehq.org/show_bug.cgi?id=47668
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |c7019a8887a3b035ce6b1ff6b11 | |3a8b5c0cc5e04 Status|STAGED |RESOLVED
--- Comment #56 from Zebediah Figura z.figura12@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commitdiff/c7019a8887a3b035ce6b1ff6b113a8b5c0cc5e04; please file a new report for further bugs with the program.
https://bugs.winehq.org/show_bug.cgi?id=47668
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #57 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.1.
https://bugs.winehq.org/show_bug.cgi?id=47668
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |5.0.x
https://bugs.winehq.org/show_bug.cgi?id=47668
m0rvj johnpgoodman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|CLOSED |REOPENED
--- Comment #58 from m0rvj johnpgoodman@gmail.com --- Sorry to reopen but having trouble with indexing in 5.7 on 64bit. 32bit works though. See Screenshot
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #59 from m0rvj johnpgoodman@gmail.com --- Created attachment 67117 --> https://bugs.winehq.org/attachment.cgi?id=67117 shows activity finished but not reporting so
You can see the indexer is apparently finished. Not sure how we would know but in the top right only reports 53%.
https://bugs.winehq.org/show_bug.cgi?id=47668
--- Comment #60 from m0rvj johnpgoodman@gmail.com --- 32 bit is scheduled for deprecation this year... so I'm keen to get 64bit reliable!
https://bugs.winehq.org/show_bug.cgi?id=47668
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|REOPENED |RESOLVED
--- Comment #61 from Nikolay Sivov bunglehead@gmail.com --- Please open another bug report for new issue on 64-bit. This one is fixed.
https://bugs.winehq.org/show_bug.cgi?id=47668
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #62 from Nikolay Sivov bunglehead@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=47668
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|5.0.x |---
--- Comment #63 from Michael Stefaniuc mstefani@winehq.org --- Removing the 5.0.x milestone from bug fixes included in 5.0.1.
https://bugs.winehq.org/show_bug.cgi?id=47668
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|kernelbase |kernel32
https://bugs.winehq.org/show_bug.cgi?id=47668
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- URL|https://downloads.logoscdn. |https://web.archive.org/web |com/LBS8/Installer/8.7.0.00 |/20210209172851/https://dow |39/Logos-x86.msi |nloads.logoscdn.com/LBS8/In | |staller/8.7.0.0039/Logos-x8 | |6.msi