[Bug 45357] New: Proprietary program using solidframework libraries crashing ( works in Windows)
https://bugs.winehq.org/show_bug.cgi?id=45357 Bug ID: 45357 Summary: Proprietary program using solidframework libraries crashing (works in Windows) Product: Wine Version: 3.10 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: s.jegen(a)gmail.com Distribution: --- Created attachment 61656 --> https://bugs.winehq.org/attachment.cgi?id=61656 Backtrace shown in the debug window We have a proprietary (sadly) program, "solid-program", which uses the proprietary Solidframework PDF libraries that crashes after seeming to work for a while. An earlier version of the same program worked in Wine but activating OCR functionality (which makes it use more libraries I assume) makes it crash. Running the same "solid-program" on Windows 10 works without issues. Attached are the backtrace (no function names. Not even for the (small) "solid-program" binary for which I have the source) and the debugging output with the +relay option. The exception seems to come from some bogus value being read in the proprietary library. I cannot figure out why the proprietary library ends up reading that value in Wine but not in Windows. I tried to run winedbg with "solid-framework" but I don't get any output: $ winedbg /opt/solid-program/solid-program.exe -t docx -p "" test-files/simple-text.pdf WineDbg starting on pid 006b 0x000000007bc969f5 DbgBreakPoint+0x1 in ntdll: ret Wine-dbg>c 006c:fixme:kernelbase:AppPolicyGetProcessTerminationMethod 0xfffffffffffffffa, 0x23fbd0 Process of pid=006b has terminated I tried to attach to the program (while the crash window is showing) but I get an error 5 (permission denied?): Wine-dbg>info proc pid threads executable (all id:s are in hex) 0000007d 1 'winedbg.exe' 00000074 1 'solid-program.exe' 00000076 1 \_ 'winedbg.exe' 00000078 4 \_ 'explorer.exe' 00000037 1 'winedbg.exe' 0000000e 5 'services.exe' 0000002a 4 \_ 'winedevice.exe' 00000025 3 \_ 'plugplay.exe' 0000001d 4 \_ 'winedevice.exe' Wine-dbg>attach 0x00000074 Can't attach process 0074: error 5 Any ideas? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #1 from Silvan <s.jegen(a)gmail.com> --- Created attachment 61657 --> https://bugs.winehq.org/attachment.cgi?id=61657 Winedebug +relay output -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 Silvan <s.jegen(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86 |x86-64 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |dotnet CC| |focht(a)gmx.net Summary|Proprietary program using |Proprietary .NET 4.x |solidframework libraries |program using Solid |crashing (works in Windows) |Framework .NET libraries | |and OCR crashes --- Comment #2 from Anastasius Focht <focht(a)gmx.net> --- Hello Silvan, since it's inside a third-party library and no download is available it's hard to tell. From your relay log: --- snip --- ... 0009:Call KERNEL32.LoadLibraryA(0023f0d0 "SolidFrameworkNative.dll") ret=140035341 ... 0009:Call PE DLL (proc=0x9b1efc,module=0x810000 L"SolidFrameworkNative.dll",reason=PROCESS_ATTACH,res=(nil)) ... 0009:Ret PE DLL (proc=0x9b1efc,module=0x810000 L"SolidFrameworkNative.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 0009:Ret KERNEL32.LoadLibraryA() retval=00810000 ret=140035341 ... 0009:Call KERNEL32.GetProcAddress(00810000,00479c00 "SWIGRegisterWStringCallback_SolidFrameworkNative") ret=14003544b 0009:Ret KERNEL32.GetProcAddress() retval=00813140 ret=14003544b ... 0009:Call KERNEL32.GetProcAddress(00810000,00479c00 "SWIGRegisterStringCallback_SolidFrameworkNative") ret=14003544b 0009:Ret KERNEL32.GetProcAddress() retval=00813130 ret=14003544b ... 0009:Call KERNEL32.GetProcAddress(00810000,00479c00 "RegisterSolidExceptionsCallbacks") ret=14003544b 0009:Ret KERNEL32.GetProcAddress() retval=008135f0 ret=14003544b ... 0009:Call KERNEL32.GetProcAddress(00810000,00479c00 "SWIGRegisterExceptionCallbacks_SolidFrameworkNative") ret=14003544b 0009:Ret KERNEL32.GetProcAddress() retval=00813090 ret=14003544b ... 0009:Call KERNEL32.GetProcAddress(00810000,00479c00 "SWIGRegisterExceptionArgumentCallbacks_SolidFrameworkNative") ret=14003544b 0009:Ret KERNEL32.GetProcAddress() retval=00813110 ret=14003544b ... 0009:Call KERNEL32.GetProcAddress(00810000,004798e0 "CSharp_new_SolidFramework_Converters_PdfToWordConverterBase") ret=14003544b 0009:Ret KERNEL32.GetProcAddress() retval=00832160 ret=14003544b ... 0009:Call KERNEL32.RaiseException(e06d7363,00000001,00000004,0023ed00) ret=7f2c9cb9afb5 ... 0009:Call ntdll.RtlUnwindEx(0023f290,00832199,0023d670,00000000,0023d810,00000000) ret=7f2c9cba9a38 ... 0009:Call msvcr120.?what(a)exception@std@@UEBAPEBDXZ(0023ee98) ret=008136ad 0009:Ret msvcr120.?what(a)exception@std@@UEBAPEBDXZ() retval=02b31fa0 ret=008136ad 0009:Call KERNEL32.GetLastError() ret=00289274 0009:Ret KERNEL32.GetLastError() retval=000000b7 ret=00289274 ... 0009:Call KERNEL32.GetProcAddress(00810000,0048c830 "CSharp_delete_SolidFramework_Converters_PdfToOfficeDocumentConverter") ret=14003544b 0009:Ret KERNEL32.GetProcAddress() retval=00822dd0 ret=14003544b 0009:Call KERNEL32.HeapValidate(00010000,00000000,0048c800) ret=002c1501 0009:Ret KERNEL32.HeapValidate() retval=00000001 ret=002c1501 0009:Call ntdll.RtlFreeHeap(00010000,00000000,0048c800) ret=002c362d 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=002c362d 0009:Call KERNEL32.HeapValidate(00010000,00000000,004858a0) ret=002c1501 0009:Ret KERNEL32.HeapValidate() retval=00000001 ret=002c1501 0009:Call ntdll.RtlFreeHeap(00010000,00000000,004858a0) ret=002c362d 0009:Ret ntdll.RtlFreeHeap() retval=00000001 ret=002c362d 0009:Call ntdll.RtlWakeAllConditionVariable(14047f330) ret=140277004 0009:Ret ntdll.RtlWakeAllConditionVariable() retval=00000000 ret=140277004 0009:Call KERNEL32.GetLastError() ret=0024805f 0009:Ret KERNEL32.GetLastError() retval=000000b7 ret=0024805f ... 0009:Ret KERNEL32.GetLastError() retval=000000b7 ret=0024805f 0009:Call KERNEL32.GetLastError() ret=0024805f 0009:Ret KERNEL32.GetLastError() retval=000000b7 ret=0024805f 0009:Call KERNEL32.GetLastError() ret=0028924b 0009:Ret KERNEL32.GetLastError() retval=000000b7 ret=0028924b wine: Unhandled page fault on read access to 0xffffffffffffffff at address 0x822ddf (thread 0009), starting debugger... ... Unhandled exception: page fault on read access to 0xffffffffffffffff in 64-bit code (0x0000000000822ddf). Register dump: rip:0000000000822ddf rsp:000000000023a640 rbp:000000000023f3f0 eflags:00010202 ( R- -- I - - - ) rax:0000000000000000 rbx:000000000023fe20 rcx:cccccccccccccccc rdx:000000000000000d rsi:000000000023aa60 rdi:000000000023a6e0 r8:0000000000000000 r9:0000000000451fc8 r10:0000000000000002 r11:0000000000451f68 r12:000000000023b180 r13:000000000023f3f0 r14:00007fffffea8000 r15:000000007bd123a0 Stack dump: 0x000000000023a640: cccccccccccccccc cccccccccccccccc 0x000000000023a650: 0000000000822dd0 cccccccccccccccc 0x000000000023a660: 000000000023a6e0 000000014024116a 0x000000000023a670: 000000000023fe20 000000000023a690 ... Backtrace: =>0 0x0000000000822ddf in solidframeworknative (+0x12ddf) (0x000000000023f3f0) 1 0x000000014024116a in solid-program (+0x241169) (0x000000000023f3f0) 2 0x000000014003c15e in solid-program (+0x3c15d) (0x000000000023f3f0) ... 0x0000000000822ddf: movq 0x0000000000000008(%rcx),%rbx Modules: Module Address Debug info Name (144 modules) PE 240000- 261000 Export vcruntime140d PE 270000- 42a000 Deferred ucrtbased PE 540000- 5d7000 Deferred spal PE 810000- bed000 Export solidframeworknative PE bf0000- c21000 Deferred dbcore PE c30000- db4000 Deferred solidcore PE dc0000- edd000 Deferred imagetool PE ee0000- 15e6000 Deferred pdflibtool PE 15f0000- 16cb000 Deferred securepdfsdk ... ---snip --- For me it looks like the problem is already at instantiating some object through native->manager wrapper. 'CSharp_new_SolidFramework_Converters_PdfToWordConverterBase' -> throws C++ exception The crash could be the result of some buggy error handling on teardown due to failure to instantiate some object. As said: hard to tell without debugging. Check that everything has been properly installed, especially the needed MS .NET Frameworks, GAC registration of 3rd party assemblies etc. Maybe you can replicate the problem with some example app using the .NET framework libs from the 3rd party vendor website? https://solidframework.net/ http://www.soliddocuments.com/frameworksample.htm?subject=CPlusSample http://www.solidframework.net/SDK-Reference/class_solid_framework_1_1_conver... http://www.solidframework.net/SDK-Reference/class_solid_framework_1_1_conver... Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #3 from Silvan <s.jegen(a)gmail.com> --- Thanks for having a look! (In reply to Anastasius Focht from comment #2)
For me it looks like the problem is already at instantiating some object through native->manager wrapper.
'CSharp_new_SolidFramework_Converters_PdfToWordConverterBase' -> throws C++ exception
Ah, I missed that.
The crash could be the result of some buggy error handling on teardown due to failure to instantiate some object. As said: hard to tell without debugging.
Is there any way I can get debugging information for the solid-program.exe for which I have the source? Apparently the PDB file is not usable here.
Check that everything has been properly installed, especially the needed MS .NET Frameworks, GAC registration of 3rd party assemblies etc.
I will check!
Maybe you can replicate the problem with some example app using the .NET framework libs from the 3rd party vendor website?
http://www.soliddocuments.com/frameworksample.htm?subject=CPlusSample
http://www.solidframework.net/SDK-Reference/ class_solid_framework_1_1_converters_1_1_pdf_to_text_converter_base.html
http://www.solidframework.net/SDK-Reference/ class_solid_framework_1_1_converters_1_1_pdf_to_text_converter.html
Our code is heavily based on their example code and used to work. Now after only changing one line (resulting in more dependencies being required) the program has started to crash. More specifically, we set https://solidframework.net/SDK-Reference/class_solid_framework_1_1_converter... to use SolidOCR and now our program doesn't work in Wine anymore. It seems somewhat likely that it makes use of more .NET libraries now and something is missing? I will investigate some more. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #4 from Silvan <s.jegen(a)gmail.com> --- (In reply to Silvan from comment #3)
Thanks for having a look!
(In reply to Anastasius Focht from comment #2)
For me it looks like the problem is already at instantiating some object through native->manager wrapper.
'CSharp_new_SolidFramework_Converters_PdfToWordConverterBase' -> throws C++ exception
Ah, I missed that.
[...]
SolidOCR and now our program doesn't work in Wine anymore.
It seems somewhat likely that it makes use of more .NET libraries now and something is missing? I will investigate some more.
According to https://www.soliddocuments.com/download.htm?product=SolidFramework the only requirement is .NET Framework 4.0 or later. I tested several versions (4.0, 4.5, 4.62) but encountered the same issue each time. I ran the still working old version of the code with WINEDEBUG=+relay and now suspect that the issue may be due to the development license. The development license I currently use depends on the machine ID which is generated by a Solid-Framework-provided program and is specific to the machine that you run that tool on. I now suspect that validating that machine specific ID fails when running the code in Wine. I will try running the program through wine again after I have the production license which is not machine-specific and thus should not try to derive some machine-specific ID at runtime. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #5 from Silvan <s.jegen(a)gmail.com> --- (In reply to Silvan from comment #4)
I ran the still working old version of the code with WINEDEBUG=+relay and now suspect that the issue may be due to the development license. The development license I currently use depends on the machine ID which is generated by a Solid-Framework-provided program and is specific to the machine that you run that tool on. I now suspect that validating that machine specific ID fails when running the code in Wine.
The program used to generate the machine-specific ID for Solid also crashes in Wine. I wonder if that indicates that getting the machine ID is what crashes our program in wine as well... Is there interest in having a look at this ID-generating program by Solid? I can attach it (I assume that that shouldn't be an issue since you can get it for free on their development portal) if there is interest. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #6 from Anastasius Focht <focht(a)gmx.net> --- Hello Silvan, --- quote --- Is there interest in having a look at this ID-generating program by Solid? --- quote --- sure, send me a download link to my email (hover over my name) and I will take a look. I prefer something without site/forum registration. --- quote --- I can attach it (I assume that that shouldn't be an issue since you can get it for free on their development portal) if there is interest. --- quote --- No, binaries you have no right to redistribute shall not be attached in Wine Bugzilla - even if they are publicly accessible. https://wiki.winehq.org/Bugs --- quote --- Don't attach large files such as executables unless they are explicitly requested (link to a legitimate download page instead) --- quote --- Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #7 from Silvan <s.jegen(a)gmail.com> --- (In reply to Anastasius Focht from comment #6)
--- quote --- Is there interest in having a look at this ID-generating program by Solid? --- quote ---
sure, send me a download link to my email (hover over my name) and I will take a look. I prefer something without site/forum registration.
Thanks for having a look. I sent you an email.
--- quote --- I can attach it (I assume that that shouldn't be an issue since you can get it for free on their development portal) if there is interest. --- quote ---
No, binaries you have no right to redistribute shall not be attached in Wine Bugzilla - even if they are publicly accessible.
--- quote --- Don't attach large files such as executables unless they are explicitly requested (link to a legitimate download page instead) --- quote ---
Yeah, I was afraid something like that would be the case. Cheers, Silvan -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #8 from Anastasius Focht <focht(a)gmx.net> --- Hi Silvan --- quote --- The program used to generate the machine-specific ID for Solid also crashes in Wine. I wonder if that indicates that getting the machine ID is what crashes our program in wine as well... ... Thanks for having a look. I sent you an email. --- quote --- Thanks for the app. Easy one, I didn't even need to debug it. --- snip --- $ WINEDEBUG=+seh,+relay wine ./SolidMachineID.exe >>log.txt 2>&1 ... 002e:Call KERNEL32.GetVolumeInformationA(004155e4 "C:\\",0033fb90,00000104,0033fb78,00000000,00000000,00000000,00000000) ret=004017e0 002e:Ret KERNEL32.GetVolumeInformationA() retval=00000001 ret=004017e0 002e:Call KERNEL32.GetLastError() ret=004068f1 002e:Ret KERNEL32.GetLastError() retval=00000042 ret=004068f1 002e:Call KERNEL32.GetLastError() ret=004068f1 002e:Ret KERNEL32.GetLastError() retval=00000042 ret=004068f1 002e:Call ntdll.RtlAllocateHeap(00110000,00000000,00000018) ret=00404e86 002e:Ret ntdll.RtlAllocateHeap() retval=0015fbf8 ret=00404e86 002e:Call KERNEL32.RaiseException(e06d7363,00000001,00000003,0033fa88) ret=00403c96 002e:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b446fba ip=7b446fba tid=002e 002e:trace:seh:raise_exception info[0]=19930520 002e:trace:seh:raise_exception info[1]=0033faa4 002e:trace:seh:raise_exception info[2]=00415cd8 002e:trace:seh:raise_exception eax=7b4356b1 ebx=0033fb44 ecx=00000000 edx=0033fa6c esi=0033fa6c edi=0033fa30 002e:trace:seh:raise_exception ebp=0033fa08 esp=0033f9a4 cs=330023 ds=33002b es=f7be002b fs=f7be0063 gs=f7be006b flags=00000212 002e:trace:seh:call_stack_handlers calling handler at 0x40fdef code=e06d7363 flags=1 002e:Call KERNEL32.GetLastError() ret=004068f1 ... 002e:Call KERNEL32.IsDebuggerPresent() ret=004055f4 002e:Ret KERNEL32.IsDebuggerPresent() retval=00000000 ret=004055f4 002e:Call KERNEL32.SetUnhandledExceptionFilter(00000000) ret=0040781d 002e:Ret KERNEL32.SetUnhandledExceptionFilter() retval=004065f2 ret=0040781d 002e:Call KERNEL32.UnhandledExceptionFilter(0033f158) ret=00407826 wine: Unhandled exception 0x40000015 in thread 2e at address 0x4065da (thread 002e), starting debugger... 002e:trace:seh:start_debugger Starting debugger "winedbg --auto 45 92" 002e:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=00407826 002e:Call KERNEL32.GetModuleHandleExW(00000000,0041112c,0033f41c) ret=00404f17 002e:Ret KERNEL32.GetModuleHandleExW() retval=00000000 ret=00404f17 002e:Call KERNEL32.ExitProcess(00000003) ret=00404f4b --- snip --- The app expects a non-empty serial number for drive 'C:' -> bug 17823 You could use Wine-Staging (prefix update!) or manually assign a serial in 'winecfg' to the virtual drive. Please check if it helps the main app too. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #9 from Silvan <s.jegen(a)gmail.com> --- Created attachment 61729 --> https://bugs.winehq.org/attachment.cgi?id=61729 Winedebug +seh +relay output after C: serial change -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #10 from Silvan <s.jegen(a)gmail.com> --- (In reply to Anastasius Focht from comment #8)
Hi Silvan
--- quote --- The program used to generate the machine-specific ID for Solid also crashes in Wine. I wonder if that indicates that getting the machine ID is what crashes our program in wine as well...
... Thanks for having a look. I sent you an email. --- quote ---
Thanks for the app. Easy one, I didn't even need to debug it.
--- snip --- $ WINEDEBUG=+seh,+relay wine ./SolidMachineID.exe >>log.txt 2>&1 ... 002e:Call KERNEL32.GetVolumeInformationA(004155e4 "C:\\",0033fb90,00000104,0033fb78,00000000,00000000,00000000,00000000) ret=004017e0 002e:Ret KERNEL32.GetVolumeInformationA() retval=00000001 ret=004017e0 002e:Call KERNEL32.GetLastError() ret=004068f1 002e:Ret KERNEL32.GetLastError() retval=00000042 ret=004068f1 002e:Call KERNEL32.GetLastError() ret=004068f1 002e:Ret KERNEL32.GetLastError() retval=00000042 ret=004068f1 002e:Call ntdll.RtlAllocateHeap(00110000,00000000,00000018) ret=00404e86 002e:Ret ntdll.RtlAllocateHeap() retval=0015fbf8 ret=00404e86 002e:Call KERNEL32.RaiseException(e06d7363,00000001,00000003,0033fa88) ret=00403c96 002e:trace:seh:raise_exception code=e06d7363 flags=1 addr=0x7b446fba ip=7b446fba tid=002e 002e:trace:seh:raise_exception info[0]=19930520 002e:trace:seh:raise_exception info[1]=0033faa4 002e:trace:seh:raise_exception info[2]=00415cd8 002e:trace:seh:raise_exception eax=7b4356b1 ebx=0033fb44 ecx=00000000 edx=0033fa6c esi=0033fa6c edi=0033fa30 002e:trace:seh:raise_exception ebp=0033fa08 esp=0033f9a4 cs=330023 ds=33002b es=f7be002b fs=f7be0063 gs=f7be006b flags=00000212 002e:trace:seh:call_stack_handlers calling handler at 0x40fdef code=e06d7363 flags=1 002e:Call KERNEL32.GetLastError() ret=004068f1 ... 002e:Call KERNEL32.IsDebuggerPresent() ret=004055f4 002e:Ret KERNEL32.IsDebuggerPresent() retval=00000000 ret=004055f4 002e:Call KERNEL32.SetUnhandledExceptionFilter(00000000) ret=0040781d 002e:Ret KERNEL32.SetUnhandledExceptionFilter() retval=004065f2 ret=0040781d 002e:Call KERNEL32.UnhandledExceptionFilter(0033f158) ret=00407826 wine: Unhandled exception 0x40000015 in thread 2e at address 0x4065da (thread 002e), starting debugger... 002e:trace:seh:start_debugger Starting debugger "winedbg --auto 45 92" 002e:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=00407826 002e:Call KERNEL32.GetModuleHandleExW(00000000,0041112c,0033f41c) ret=00404f17 002e:Ret KERNEL32.GetModuleHandleExW() retval=00000000 ret=00404f17 002e:Call KERNEL32.ExitProcess(00000003) ret=00404f4b --- snip ---
The app expects a non-empty serial number for drive 'C:' -> bug 17823
You could use Wine-Staging (prefix update!) or manually assign a serial in 'winecfg' to the virtual drive.
I used 'winecfg' to change the serial of C:\ to "78A1" which is half of the serial number that the command "vol C:" was showing me on my Windows dev machine. The "vol" command on my Windows dev machine returns "78A1-8192" which 'winecfg' truncates to only the part before the dash. Maybe dashes are not allowed there? After that, the ID generating program worked fine, thanks for that!
Please check if it helps the main app too.
On the negative side, the main program still didn't work. I attached a new WINEDEBUG=+seh,+relay debug output. When I used a Mac-specific license key on our Windows dev machine by mistake I didn't get some helpful warning but some kind of exception as well. I am now wondering if I just see the same happening in Wine. Next I will try to generate a machine-ID-specific license for the machine ID that is returned in Wine and use that license to run the program. I will report my findings afterwards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #11 from Silvan <s.jegen(a)gmail.com> --- (In reply to Silvan from comment #10)
Next I will try to generate a machine-ID-specific license for the machine ID that is returned in Wine and use that license to run the program. I will report my findings afterwards.
I tried to generate a license based on the machine ID that the ID generator returned but the Solidframework website did not accept the machine ID. It just said "Please re-check the machine ID". I compared the newly generated ID (generated in Wine) with the one I generated on my Windows dev machine. The one generated in Windows is 4 characters longer which is most likely the reason why the Wine-generated one is not being accepted. I assume something with the machine-ID generation still isn't working correctly in Wine (which may also be affecting our main program at runtime). Maybe one issue is the volume serial length? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #12 from Anastasius Focht <focht(a)gmx.net> --- Hi Silvan, --- quote --- The "vol" command on my Windows dev machine returns "78A1-8192" which 'winecfg' truncates to only the part before the dash. Maybe dashes are not allowed there? --- quote --- You need to input it without hyphens. Source: https://source.winehq.org/git/wine.git/blob/HEAD:/programs/winecfg/drive.c#l... --- snip --- 183 /* set the drive serial number via a .windows-serial file */ 184 static void set_drive_serial( WCHAR letter, DWORD serial ) 185 { 186 WCHAR filename[] = {'a',':','\\','.','w','i','n','d','o','w','s','-','s','e','r','i','a','l',0}; 187 HANDLE hFile; 188 189 filename[0] = letter; 190 WINE_TRACE("Putting serial number of %08X into file %s\n", serial, wine_dbgstr_w(filename)); 191 hFile = CreateFileW(filename, GENERIC_WRITE, FILE_SHARE_READ, NULL, 192 CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL); 193 if (hFile != INVALID_HANDLE_VALUE) 194 { 195 DWORD w; 196 char buffer[16]; 197 198 sprintf( buffer, "%X\n", serial ); 199 WriteFile(hFile, buffer, strlen(buffer), &w, NULL); 200 CloseHandle(hFile); 201 } 202 } --- snip --- Alternatively you can just create the file for drive serial number on your own, example: --- snip --- $ echo "78A18192" > ~/.wine/drive_c/.windows-serial --- snip --- --- quote --- On the negative side, the main program still didn't work. I attached a new WINEDEBUG=+seh,+relay debug output. --- quote --- Still the same trace as with comment #2 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #13 from Silvan <s.jegen(a)gmail.com> --- Hi Anastasius (In reply to Anastasius Focht from comment #12)
--- snip ---
Alternatively you can just create the file for drive serial number on your own, example:
--- snip --- $ echo "78A18192" > ~/.wine/drive_c/.windows-serial --- snip ---
I used this approach and now the machine-ID generation tool produced an ID which I could use to generate a valid dev license. Using this dev license in our program actually makes it work, thanks a lot! What we are now struggling with is that running our .exe in Wine takes about 16 times longer than when running it on Windows (Windows takes less than 1 second, in Wine it takes ~16s). I assume that something with my Wine installation (wine-3.11) must be screwed up because just running $ time wine64 nonexistingfile.exe 0012:fixme:wer:WerSetFlags (2) stub! 0012:fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub 0019:fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub. 0019:fixme:ntdll:EtwEventRegister ({319dc449-ada5-50f7-428e-957db6791668}, 0x993b10, 0x9e1b20, 0x9e1b38) stub. 0019:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0x973159, 28) stub 001c:fixme:heap:RtlSetHeapInformation 0x240000 0 0x23e830 4 stub 001c:fixme:wer:WerSetFlags (2) stub! 001c:fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub 0022:fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub. 0022:fixme:ntdll:EtwEventRegister ({319dc449-ada5-50f7-428e-957db6791668}, 0x950d00, 0x9c0260, 0x9c0280) stub. 0022:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0x998add, 28) stub 0019:fixme:service:QueryServiceConfig2W Level 6 not implemented 0019:fixme:service:QueryServiceConfig2W Level 6 not implemented 0019:fixme:service:QueryServiceConfig2W Level 6 not implemented 0019:fixme:service:QueryServiceConfig2W Level 6 not implemented 0019:fixme:service:QueryServiceConfig2W Level 6 not implemented 0022:fixme:service:QueryServiceConfig2W Level 6 not implemented 0022:fixme:service:QueryServiceConfig2W Level 6 not implemented 0022:fixme:service:QueryServiceConfig2W Level 6 not implemented 0022:fixme:service:QueryServiceConfig2W Level 6 not implemented 0022:fixme:service:QueryServiceConfig2W Level 6 not implemented 000f:err:service:process_send_command receiving command result timed out 000f:fixme:service:scmdatabase_autostart_services Auto-start service L"WineBus" failed to start: 1053 wine: cannot find L"C:\\windows\\system32\\nonexistingfile.exe" real 0m11.592s user 0m0.006s sys 0m0.010s takes 11 seconds which seems wrong. I tried updating from .NET 4 to 4.6.2 but there did not seem to be an easily observable difference. Should I open a new bug report for the speed issue? Cheers, Silvan -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #14 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Silvan from comment #13)
What we are now struggling with is that running our .exe in Wine takes about 16 times longer than when running it on Windows (Windows takes less than 1 second, in Wine it takes ~16s). I assume that something with my Wine installation (wine-3.11) must be screwed up because just running ... 000f:err:service:process_send_command receiving command result timed out 000f:fixme:service:scmdatabase_autostart_services Auto-start service L"WineBus" failed to start: 1053
I've seen this before. Does the hang go away if you disable winehid.sys? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #15 from Silvan <s.jegen(a)gmail.com> --- Hi Zebediah (In reply to Zebediah Figura from comment #14)
(In reply to Silvan from comment #13)
What we are now struggling with is that running our .exe in Wine takes about 16 times longer than when running it on Windows (Windows takes less than 1 second, in Wine it takes ~16s). I assume that something with my Wine installation (wine-3.11) must be screwed up because just running ... 000f:err:service:process_send_command receiving command result timed out 000f:fixme:service:scmdatabase_autostart_services Auto-start service L"WineBus" failed to start: 1053
I've seen this before. Does the hang go away if you disable winehid.sys?
I used winecfg to set the winehid.sys library to "disabled" but I got the same messages and a runtime of about 11s when running wine64 with a non-existing file. Running winecfg itself also takes around 10s before the window starts showing. I am quite sure that this was much faster before. If you want I could try a different Wine version (or build from git) but if that fixes the issue it could just be because it would clean my current Wine prefix... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #16 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Silvan from comment #15)
I used winecfg to set the winehid.sys library to "disabled" but I got the same messages and a runtime of about 11s when running wine64 with a non-existing file.
Er, my apologies; I meant winebus.sys. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #17 from Silvan <s.jegen(a)gmail.com> --- (In reply to Zebediah Figura from comment #16)
(In reply to Silvan from comment #15)
I used winecfg to set the winehid.sys library to "disabled" but I got the same messages and a runtime of about 11s when running wine64 with a non-existing file.
Er, my apologies; I meant winebus.sys.
This seems to have done the trick! When running wine64 with the non-existing file I now get $ time wine64 nonexistingfile.exe001c:fixme:ntdll:EtwEventUnregister (deadbeef) stub. 0012:fixme:ntdll:EtwEventUnregister (deadbeef) stub. 0012:fixme:wer:WerSetFlags (2) stub! 0012:fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub 0019:fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub. 0019:fixme:ntdll:EtwEventRegister ({319dc449-ada5-50f7-428e-957db6791668}, 0x993b10, 0x9e1b20, 0x9e1b38) stub. 0019:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0x973159, 28) stub 001c:fixme:heap:RtlSetHeapInformation 0x240000 0 0x23e830 4 stub 001c:fixme:wer:WerSetFlags (2) stub! 001c:fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub 0022:fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub. 0022:fixme:ntdll:EtwEventRegister ({319dc449-ada5-50f7-428e-957db6791668}, 0x950d00, 0x9c0260, 0x9c0280) stub. 0022:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0x998add, 28) stub 0036:err:winedevice:async_create_driver failed to create driver L"WineBus": c0000142 000f:fixme:service:scmdatabase_autostart_services Auto-start service L"WineBus" failed to start: 31 wine: cannot find L"C:\\windows\\system32\\nonexistingfile.exe" real 0m1.722s user 0m0.001s sys 0m0.006s $ time wine64 nonexistingfile.exe wine: cannot find L"C:\\windows\\system32\\nonexistingfile.exe" real 0m0.022s user 0m0.000s sys 0m0.019s $ time wine64 nonexistingfile.exe wine: cannot find L"C:\\windows\\system32\\nonexistingfile.exe" real 0m0.018s user 0m0.004s sys 0m0.012s ... The times are not very consistent but I assume that this could be related to a wine service shutting down and starting again. I can also confirm that with winebus.sys disabled our program takes about the same time as on Windows (I misremembered the time taken on Windows being 1s but it was actually 5s which is what we get through wine now as well). Do you want me to try to debug what the issue with winebus.sys is? Weirdly enough, the output of our program using the Solid OCR libraries when ran on Windows is different from what it is when ran in Wine. I am not sure that this counts as a Wine bug... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #18 from Zebediah Figura <z.figura12(a)gmail.com> --- (In reply to Silvan from comment #17)
Do you want me to try to debug what the issue with winebus.sys is?
No need; I've already got a pretty good idea, but thanks for the offer.
Weirdly enough, the output of our program using the Solid OCR libraries when ran on Windows is different from what it is when ran in Wine. I am not sure that this counts as a Wine bug...
Probably, yes; if the difference in behaviour is important please file one. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 --- Comment #19 from Silvan <s.jegen(a)gmail.com> --- (In reply to Zebediah Figura from comment #18)
(In reply to Silvan from comment #17)
Do you want me to try to debug what the issue with winebus.sys is?
No need; I've already got a pretty good idea, but thanks for the offer.
No problem!
Weirdly enough, the output of our program using the Solid OCR libraries when ran on Windows is different from what it is when ran in Wine. I am not sure that this counts as a Wine bug...
Probably, yes; if the difference in behaviour is important please file one.
Ok, then we can close this one and I will open a different one. My suggestion for the title is: "Proprietary .NET 4.x program using Solid Framework .NET PDF OCR libraries generates different Word files in Wine compared to Windows" Attaching the two differing Word file results based on a scan of one page from a text book should be allowed (fair use), correct? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Proprietary .NET 4.x |Proprietary .NET 4.x |program using Solid |program using Solid |Framework .NET libraries |Framework .NET libraries |and OCR crashes |and OCR crashes (volume/fs | |serial for "c:" must be | |non-zero for | |license/machine id | |generator) Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Component|-unknown |programs --- Comment #20 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, resolving this as dupe of bug 17823 Please discuss all other problems in separate bugs. The comment history is already a bit messed up. Regards *** This bug has been marked as a duplicate of bug 17823 *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=45357 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #21 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Closing Duplicate -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org