http://bugs.winehq.org/show_bug.cgi?id=18985
Summary: Two bugs in HTML-kit Product: Wine Version: 1.1.23 Platform: PC URL: http://htmlkit.com/download/ OS/Version: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: comctl32 AssignedTo: wine-bugs@winehq.org ReportedBy: xerox_xerox2000@yahoo.co.uk
Hi, a user reported trouble with this app here: http://ubuntuforums.org/showthread.php?t=1190483
I gave it a try and actually there seem to be two bugs:
1. All icons in toolbar are black. In the console the line appears:
err:imagelist:IMAGELIST_InternalExpandBitmaps creating new image bitmap (x=25600 y=16)!
2. After doing from the menu: Edit->Prefernces->OK an access violation occurs and the app is no longer usable.
Both bugs are gone using native comctl32
http://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #1 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2009-06-18 02:05:55 --- Created an attachment (id=21867) --> (http://bugs.winehq.org/attachment.cgi?id=21867) black corruptions in toolbar and rest of the GUI
http://bugs.winehq.org/show_bug.cgi?id=18985
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-18 03:39:30 --- Please open a separate bug report for each problem.
http://bugs.winehq.org/show_bug.cgi?id=18985
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #3 from Dmitry Timoshkov dmitry@codeweavers.com 2009-06-18 03:39:45 --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=18985
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |REOPENED Resolution|INVALID | Summary|Two bugs in HTML-kit |access violation in | |html-kit
--- Comment #4 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2009-06-21 04:23:48 --- then i'll reopen this one for the crash after doing Edit->Prefernces->OK. Adjusted the summary acoordingly.
http://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com 2009-06-22 14:01:37 --- (In reply to comment #4)
then i'll reopen this one for the crash after doing Edit->Prefernces->OK. Adjusted the summary acoordingly.
Hi, Louis.
Attach crash log please.
http://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #6 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2009-06-23 00:37:22 ---
Hi, Louis.
Attach crash log please.
Hi Nicolai, there isn't any crash log. It pops op a messagebox with "Access violation" and then exits silently. If you need traces just tell me and i'll attach t hem.
http://bugs.winehq.org/show_bug.cgi?id=18985
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |RandomAccountName@mail.com
--- Comment #7 from A Wine user RandomAccountName@mail.com 2010-01-11 03:58:42 --- Still present in Wine 1.1.36.
http://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #8 from A Wine user RandomAccountName@mail.com 2010-01-17 08:32:05 --- Created an attachment (id=25768) --> (http://bugs.winehq.org/attachment.cgi?id=25768) Backtrace from winedbg
Maybe this will be helpful?
http://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #9 from A Wine user RandomAccountName@mail.com 2010-04-07 09:54:01 --- Still present in 1.1.42 and git.
A little observation: after closing several of those access violation dialogs, it eventually produces a different error message - "list index out of bounds (0)". After closing quite a lot of error dialogs, they eventually stop appearing and the program becomes usable again, at least to an extent.
http://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #10 from Nikolay Sivov bunglehead@gmail.com 2010-06-06 16:29:15 --- (In reply to comment #9)
Still present in 1.1.42 and git.
A little observation: after closing several of those access violation dialogs, it eventually produces a different error message - "list index out of bounds (0)". After closing quite a lot of error dialogs, they eventually stop appearing and the program becomes usable again, at least to an extent.
I see there's a Listview handlers in backtrace, please attach +listview with comctl32 compiled with -O0 and the same backtrace with -O0 to get parameters listed properly. Lines are shifted apparently so I need logs running current git Wine.
http://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #11 from A Wine user RandomAccountName@mail.com 2010-06-07 08:12:47 --- Created an attachment (id=28649) --> (http://bugs.winehq.org/attachment.cgi?id=28649) +listview log (compiled with -O0)
For this log, I clicked OK to the first two error messages before killing it with wineserrver -k, just in case there's something happening repeatedly to trigger the error dialogs...
http://bugs.winehq.org/show_bug.cgi?id=18985
A Wine user RandomAccountName@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #25768|0 |1 is obsolete| |
--- Comment #12 from A Wine user RandomAccountName@mail.com 2010-06-07 08:15:56 --- Created an attachment (id=28650) --> (http://bugs.winehq.org/attachment.cgi?id=28650) Winedbg backtrace (compiled with -O0)
Of course, I may have used wineserver -k and not wineserrver -k ;)
Here's the relevant backtraces from bt all in winedbg.
http://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #13 from A Wine user RandomAccountName@mail.com 2010-12-18 10:09:28 CST --- Still present in wine-1.3.9-164-g17e66e0.
http://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #14 from Nikolay Sivov bunglehead@gmail.com 2011-05-13 11:27:03 CDT --- First patch for that is in as c6dd14199c6f48161ee8393232cb4daddb4df78d.
http://bugs.winehq.org/show_bug.cgi?id=18985
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #15 from Bruno Jesus 00cpxxx@gmail.com 2011-10-02 07:52:56 CDT --- In latest git the icons are working very well but the second issue related to the read/write access violation is still present.
http://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #16 from Austin English austinenglish@gmail.com --- In wine-1.7.8-88-gfb75292, the icons are normal. If I go to Edit, Preferences, the dialog is all black, I can't click anything.
I don't see the access violation at all.
[austin@localhost ~]$ du -h HKToolsTrialSetup.zip 17M HKToolsTrialSetup.zip [austin@localhost ~]$ sha1sum HKToolsTrialSetup.zip eedfa0e542d6ae8b98f055e868e2a74337fa6617 HKToolsTrialSetup.zip
http://bugs.winehq.org/show_bug.cgi?id=18985
hanska2@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hanska2@luukku.com
--- Comment #17 from hanska2@luukku.com --- Weird. I don't get this runnig at all.
fixme:mscoree:corruntimehost_Start stub 0x1a82c0 fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} err:mscoree:expect_no_runtimes Process exited with a Mono runtime loaded. err:ole:CoUninitialize Mismatched CoUninitialize fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046} err:ole:CoReleaseMarshalData IMarshal::ReleaseMarshalData failed with error 0x8001011d
wine 1.7.22
https://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #18 from A Wine user RandomAccountName@mail.com --- I still see the access violation in wine-1.7.15-173-ge851999.
(In reply to Austin English from comment #16)
[austin@localhost ~]$ du -h HKToolsTrialSetup.zip 17M HKToolsTrialSetup.zip [austin@localhost ~]$ sha1sum HKToolsTrialSetup.zip eedfa0e542d6ae8b98f055e868e2a74337fa6617 HKToolsTrialSetup.zip
That looks like the paid version of HTML-Kit (HTML-Kit Tools). This bug is about the free version of HTML-Kit (HTML-Kit 292) from http://www.htmlkit.com/download/#download-html-kit-292 .
https://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #19 from A Wine user RandomAccountName@mail.com --- (In reply to A Wine user from comment #18)
I still see the access violation in wine-1.7.15-173-ge851999.
Oops, that isn't the version I meant to test with. The access violation persists in wine-1.7.24-14-gd1749b5 as well.
https://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #20 from Austin English austinenglish@gmail.com --- (In reply to A Wine user from comment #19)
(In reply to A Wine user from comment #18)
I still see the access violation in wine-1.7.15-173-ge851999.
Oops, that isn't the version I meant to test with. The access violation persists in wine-1.7.24-14-gd1749b5 as well.
Where is the version that has the access violation? Sha1sum?
https://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #21 from A Wine user RandomAccountName@mail.com --- (In reply to Austin English from comment #20)
Where is the version that has the access violation? Sha1sum?
It's downloadable here: http://www.htmlkit.com/download/#download-html-kit-292
sha1sum HKSetup.exe 80977e992eb3ff09a204018d657e01b44c3b1a26 HKSetup.exe
This installer will also try to download and install the other version (HTML-Kit Tools) if you don't unckeck the option at the end (after the program files are copied).
https://bugs.winehq.org/show_bug.cgi?id=18985
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW URL|http://htmlkit.com/download |http://www.htmlkit.com/down |/ |load/#download-html-kit-292 Summary|access violation in |access violation in |html-kit |HTML-Kit 292
--- Comment #22 from Austin English austinenglish@gmail.com --- Confirming. With: [austin@localhost ~]$ sha1sum HKSetup.exe 80977e992eb3ff09a204018d657e01b44c3b1a26 HKSetup.exe [austin@localhost ~]$ du -h HKSetup.exe 2.4M HKSetup.exe [austin@localhost ~]$ wine --version wine-1.7.24-14-gd1749b5
I declined the HTML-Toolkit installation at the end of the install, then clicked no to all the updates/etc. on starting the app. Made a new file, then Edit>Preferences>OK. Access violation occurred.
https://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #23 from A Wine user RandomAccountName@mail.com --- Still in wine-1.7.42-29-ge2e1ac2.
https://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #24 from A Wine user RandomAccountName@mail.com --- Still in wine-1.9.5-160-g03ee99b.
https://bugs.winehq.org/show_bug.cgi?id=18985
Robert Giordano rob215x@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rob215x@gmail.com
--- Comment #25 from Robert Giordano rob215x@gmail.com --- HTML-Kit still crashes with Access Violation
$ wine --version wine-4.11
My System: Host: pc2019 Kernel: 4.19.49-1-MANJARO x86_64 bits: 64 compiler: gcc v: 8.3.0 Desktop: Xfce 4.13.4git-be04da Distro: Manjaro Linux
I used HTML-Kit for many years and it would be nice to have it from time to time.
First I made sure I was in 32bit mode: $ WINEARCH=win32 WINEPREFIX=$HOME/.wine winecfg - and I selected Windows XP as the operating system
Next, I downloaded HKSetup.exe (the original, free version, HTML-Kit 292)
$ cd ~/Downloads $ WINEARCH=win32 wine HKSetup.exe
I've tried two ways of launching it: $ WINEARCH=win32 wine 'c:/Program Files/Chami/HTML-Kit/Bin/HTMLKit.exe'
And, on http://www.htmlkit.com/support/docs/pages/H000134.html is says: "Change to the HTML-Kit/Bin directory and run: wine HTMLKit.exe /linux"
So I did: $ cd '/home/design215/.wine/drive_c/Program Files/Chami/HTML-Kit/Bin' $ wine HTMLKit.exe /linux
Either way, the program opens and looks fine. I can create an html document and save it.
But, as soon as I open Edit > Preferences, or make any changes that get saved in the preferences file, the program crashes and I get a dialog box that says: "Access violation at address 00000000. Read of address 00000000"
I close the dialog box a bunch of times and it keeps appearing, sometimes with different numbers like 705F4554 instead of 00000000.
I don't know if this helps any, but HTML-Kit saves its preferences in the Windows Registry. I think it does this for security so no one can easily get the passwords to all of the web sites you've saved (unless you know where to look).
Is there something that needs to be installed for programs to be able to modify the registry?
https://bugs.winehq.org/show_bug.cgi?id=18985
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |damjan.jov@gmail.com
--- Comment #26 from Damjan Jovanovic damjan.jov@gmail.com --- With WINEDEBUG='+listview' we see this line just before the messagebox:
003a:trace:listview:LISTVIEW_GetNextItem nItem=-1, uFlags=1, nItemCount=1
uFlags=1 means: #define LVNI_FOCUSED 0x0001
which means the code will take this optimized path in that function:
/* if we're asked for the focused item, that's only one, * so it's worth optimizing */ if (uFlags & LVNI_FOCUSED) { if ((LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) != uMask) return -1; return (infoPtr->nFocusedItem == nItem) ? -1 : infoPtr->nFocusedItem; }
What is returned, and from which return statement?
https://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #27 from Damjan Jovanovic damjan.jov@gmail.com --- Created attachment 65697 --> https://bugs.winehq.org/attachment.cgi?id=65697 patch to debug return path
With this patch to enhance debugging, and a WINEDEBUG='+listview,+relay,+seh' trace, we get this:
0041:trace:listview:LISTVIEW_GetNextItem nItem=-1, uFlags=1, nItemCount=1 0041:Call msvcrt.memset(003181a0,00000000,00000018) ret=6373a719 0041:Ret msvcrt.memset() retval=003181a0 ret=6373a719 0041:err:listview:LISTVIEW_GetNextItem LISTVIEW_GetNextItem() returning -1 from mask not matching 0041:Ret window proc 0x63733f70 (hwnd=0x7010c,msg=LVM_GETNEXTITEM,wp=ffffffff,lp=00000001) retval=ffffffff 0041:Ret user32.CallWindowProcA() retval=ffffffff ret=0080daf5 0041:Ret window proc 0x1300176 (hwnd=0x7010c,msg=LVM_GETNEXTITEM,wp=ffffffff,lp=00000001) retval=ffffffff 0041:Ret user32.SendMessageA() retval=ffffffff ret=007f277f 0041:Call user32.InvalidateRect(00070206,0031aa08,00000000) ret=0080bb29 0041:Ret user32.InvalidateRect() retval=00000001 ret=0080bb29 0041:trace:seh:raise_exception code=c0000005 flags=0 addr=0x0 ip=00000000 tid=0041
So LISTVIEW_GetNextItem() returns -1 due to failing on:
if ((LISTVIEW_GetItemState(infoPtr, infoPtr->nFocusedItem, uMask) & uMask) != uMask) { ERR("LISTVIEW_GetNextItem() returning -1 from mask not matching\n"); return -1; }
https://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #28 from Damjan Jovanovic damjan.jov@gmail.com --- Created attachment 65786 --> https://bugs.winehq.org/attachment.cgi?id=65786 hack to disable listview notifications
This hack stops HTMLKit from crashing. It stops the listview control from ever sending out notifications.
It's definitely the wrong approach, and breaks other things, eg. in winecfg you can't see the Windows version. But it must do something right for this app. What?
Step 3: Application crashes, message box reports the access violation: 17 0x6334ebb9 MessageBoxA+0x58() in user32 (0x0031a438) 18 0x0080825e in htmlkit (+0x40825d) (0x0031a474) 19 0x0080832e in htmlkit (+0x40832d) (0x0031a59c) 20 0x00477766 in htmlkit (+0x77765) (0x0031a5d0) 21 0x008081f7 in htmlkit (+0x4081f6) (0x0031ac9c) 22 0x00801976 in htmlkit (+0x401975) (0x0031acb4)
Step 2: Callback into the application: 23 0x633b38bc WINPROC_wrapper+0x1b() in user32 (0x0031ace4) 24 0x633b578d call_window_proc+0x12c() in user32 (0x0031ad80) 25 0x633b75bc WINPROC_CallProcWtoA+0x151b() in user32 (0x0031c084) 26 0x633b5bf5 WINPROC_call_window+0x384() in user32 (0x0031c198) 27 0x63344f90 call_window_proc+0x12f() in user32 (0x0031c238) 28 0x6333d1e0 send_message+0x1bf() in user32 (0x0031c2c8) 29 0x6333d535 SendMessageW+0x94() in user32 (0x0031c33c) 30 0x637591d0 notify_hdr+0xdf() in comctl32 (0x0031c398) 31 0x6375c40c notify_listview+0xab() in comctl32 (0x0031c3e0)
Step 1: Application sent LVM_SETITEMTEXT, LISTVIEW_SetItemText() ran: 32 0x63762c9f set_main_item+0xa8e() in comctl32 (0x0031c538) 33 0x6374d9ad LISTVIEW_SetItemT+0x1fc() in comctl32 (0x0031c5b8) 34 0x6374e6e7 LISTVIEW_SetItemTextT+0x156() in comctl32 (0x0031c658) 35 0x63743e04 LISTVIEW_WindowProc+0x1ee3() in comctl32 (0x0031c964) 36 0x633b38bc WINPROC_wrapper+0x1b() in user32 (0x0031c994) 37 0x633b578d call_window_proc+0x12c() in user32 (0x0031ca30) 38 0x633b5370 WINPROC_CallProcAtoW+0x157f() in user32 (0x0031e948) 39 0x633b778a CallWindowProcA+0x1a9() in user32 (0x0031e9d8) 40 0x0080daf5 in htmlkit (+0x40daf4) (0x00020286)
ie. chain of events
+-------------------------------------------------------+ | Application 3.Internal processing -> crash | +-------------------------------------------------------+ | ^ | 1.LVM_SETITEMTEXT | 2.SendMessage() [re-entry] v | +----------------------------------------+ | comctl32.dll listview control | +----------------------------------------+
https://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #29 from Damjan Jovanovic damjan.jov@gmail.com --- Why does that message crash the application? It's one or more of the following: 1. The message contents are wrong. 2. The message is sent when it shouldn't be. 3. The message is sent synchronously using SendMessage() instead of asynchronously using PostMessage(). 4. The message and its timing are right, but the listview state is wrong in some other way, and that message just triggers the processing that crashes as a result of that wrongness.
(Hopefully it's one of the easier cases, as dlls/comctl32/listview.c is 11948 lines long...)
1. A WINEDEBUG='+listview' log shows: 002c:trace:listview:notify_listview (code=-101, plvnm=iItem=0, iSubItem=0, uNewState=0x0, uOldState=0x0, uChanged=0x1, ptAction=(0,0), lParam=26371760) which is also sent earlier and doesn't crash. 2. Nope. It gets sent the same way several times, only the 4th time crashes. 3. Not possible, our tests use SendMessage() too. 4. Sadly, this is probably it.
https://bugs.winehq.org/show_bug.cgi?id=18985
--- Comment #30 from Damjan Jovanovic damjan.jov@gmail.com --- The stack trace is lost by the call to SEH handlers. By setting a breakpoint on the first SEH handler, a better stack trace can be obtained:
=>0 0x0081f9fe in htmlkit (+0x41f9fe) (0x0031a634) 1 0x628e33eb EXC_CallHandler+0x1a() in ntdll (0x0031a654) 2 0x628e946e call_stack_handlers+0x10d(rec=0x31aaf4, context=0x31a828) [Z:\home\user\Wine\wine\dlls\ntdll\signal_i386.c:662] in ntdll (0x0031a6d0) 3 0x628e6c9d raise_exception+0x41c(rec=0x31aaf4, context=0x31a828, first_chance=0x1) [Z:\home\user\Wine\wine\dlls\ntdll\signal_i386.c:736] in ntdll (0x0031a7d8) 4 0x628e858c raise_generic_exception+0x3b(rec=0x31aaf4, context=0x31a828) [Z:\home\user\Wine\wine\dlls\ntdll\signal_i386.c:1863] in ntdll (0x0031a818) 5 0xdeadbabe (0x0031ab88) 6 0x007e28c1 in htmlkit (+0x3e28c0) (0x0031abc0) 7 0x0080c008 in htmlkit (+0x40c007) (0x0031ac1c) 8 0x0080db30 in htmlkit (+0x40db2f) (0x0031ac9c) 9 0x00801976 in htmlkit (+0x401975) (0x0031acb4) 10 0x633b389c WINPROC_wrapper+0x1b() in user32 (0x0031ace4) 11 0x633b576d call_window_proc+0x12c(hwnd=0x10282, msg=0x4e, wp=0x20286, lp=0x31c4f0, result=0x31c220, arg=0x1300190) [Z:\home\user\Wine\wine\dlls\user32\winproc.c:249] in user32 (0x0031ad80) 12 0x633b759c WINPROC_CallProcWtoA+0x151b(callback=0x633b5640, hwnd=0x10282, msg=0x4e, wParam=0x20286, lParam=0x31c4f0, result=0x31c220, arg=0x1300190) [Z:\home\user\Wine\wine\dlls\user32\winproc.c:864] in user32 (0x0031c084) 13 0x633b5bd5 WINPROC_call_window+0x384(hwnd=0x10282, msg=0x4e, wParam=0x20286, lParam=0x31c4f0, result=0x31c220, unicode=0x1, mapping=1664702431) [Z:\home\user\Wine\wine\dlls\user32\winproc.c:926] in user32 (0x0031c198) 14 0x63344f70 call_window_proc+0x12f(hwnd=0x10282, msg=0x4e, wparam=0x20286, lparam=0x31c4f0, unicode=0x1, same_thread=0x1, mapping=1664702431) [Z:\home\user\Wine\wine\dlls\user32\message.c:2225] in user32 (0x0031c238) 15 0x6333d1c0 send_message+0x1bf(info=0x31c2e8, res_ptr=0x31c318, unicode=0x1) [Z:\home\user\Wine\wine\dlls\user32\message.c:3294] in user32 (0x0031c2c8) 16 0x6333d515 SendMessageW+0x94(hwnd=0x10282, msg=0x4e, wparam=0x20286, lparam=0x31c4f0) [Z:\home\user\Wine\wine\dlls\user32\message.c:3495] in user32 (0x0031c33c) 17 0x637591f0 notify_hdr+0xdf(infoPtr=0x1d4ce8, code=0xffffff9b, pnmh=0x31c4f0) [Z:\home\user\Wine\wine\dlls\comctl32\listview.c:838] in comctl32 (0x0031c398) 18 0x6375c41c notify_listview+0xab(infoPtr=0x1d4ce8, code=0xffffff9b, plvnm=0x31c4f0) [Z:\home\user\Wine\wine\dlls\comctl32\listview.c:888] in comctl32 (0x0031c3e0) 19 0x63762c9f set_main_item+0xa8e(infoPtr=0x1d4ce8, lpLVItem=0x31c600, isNew=0, isW=0x1, bChanged=0x31c590) [Z:\home\user\Wine\wine\dlls\comctl32\listview.c:4368] in comctl32 (0x0031c538) 20 0x6374d9cd LISTVIEW_SetItemT+0x1fc(infoPtr=0x1d4ce8, lpLVItem=0x31c600, isW=0) [Z:\home\user\Wine\wine\dlls\comctl32\listview.c:4490] in comctl32 (0x0031c5b8) 21 0x6374e707 LISTVIEW_SetItemTextT+0x156(infoPtr=0x1d4ce8, nItem=0, lpLVItem=0x31ee30, isW=0) [Z:\home\user\Wine\wine\dlls\comctl32\listview.c:9117] in comctl32 (0x0031c658) 22 0x63743e24 LISTVIEW_WindowProc+0x1ee3(hwnd=0x20286, uMsg=0x102e, wParam=0, lParam=0x31ee30) [Z:\home\user\Wine\wine\dlls\comctl32\listview.c:11691] in comctl32 (0x0031c964) 23 0x633b389c WINPROC_wrapper+0x1b() in user32 (0x0031c994) 24 0x633b576d call_window_proc+0x12c(hwnd=0x20286, msg=0x102e, wp=0, lp=0x31ee30, result=0x31e99c, arg=0x63741f40) [Z:\home\user\Wine\wine\dlls\user32\winproc.c:249] in user32 (0x0031ca30) 25 0x633b5350 WINPROC_CallProcAtoW+0x157f(callback=0x633b5640, hwnd=0x20286, msg=0x102e, wParam=0, lParam=0x31ee30, result=0x31e99c, arg=0x63741f40, mapping=WMCHAR_MAP_CALLWINDOWPROC) [Z:\home\user\Wine\wine\dlls\user32\winproc.c:609] in user32 (0x0031e948) 26 0x633b776a CallWindowProcA+0x1a9(func=0xffff0015, hwnd=0x20286, msg=0x102e, wParam=0, lParam=0x31ee30) [Z:\home\user\Wine\wine\dlls\user32\winproc.c:1010] in user32 (0x0031e9d8) 27 0x0080daf5 in htmlkit (+0x40daf4) (0x00020286)
Frame 6 is where the crash happens.
Wine-dbg>disassemble 0x007e28bb 0x007e28bb: call *0x188(%ebx) 0x007e28c1: popl %ebx 0x007e28c2: ret
0x188(%ebx) is NULL, leading to a call to a NULL function pointer -> crash.
A structure of that size (at least 396 bytes) is something internal to the application, not something we pass. Why it's NULL, how it became NULL, requires an understanding of the application's internals, which is best obtained with the help of the author.