KernelEx Apps Compatibility List (New)

[jumper]

I've been investigating the "why" and part of the answer is obvious: something about the new GCC linker output is incompatible with either the 9x/Me or KernelEx loaders. UPX has its own two-stage loader that is compatible with both 9x/Me/Kex and GCC and that is how UPXing solves the problem.

I compared VLC 2.1.2 and 2.1.3 and Libvlccore.dll was the only dll that acted differently for me in LoadLibrary between versions (2.1.2 loaded, 2.1.3 GPF'd twice in the init routine)

IHATOOL caused an invalid page fault inmodule COPY OF LIBVLCCORE.DLL at 016f:6a62d2a3.Registers:EAX=00000006 CS=016f EIP=6a62d2a3 EFLGS=00010246EBX=00000001 SS=0177 ESP=0063fb28 EBP=0063fb30ECX=c1978bb0 DS=0177 ESI=6a540000 FS=40d7EDX=bffc9310 ES=0177 EDI=00000000 GS=0000Bytes at CS:EIP:a3 cc e3 66 6a a1 cc e3 66 6a 83 f8 ff 75 05 e8 Stack dump:6a540000 00000002 0063fb80 6a65baca bff9ed8f 0063fb60 0063fb80 00000001 6a540000 00000000 00000001 6a541305 6a540000 00000001 00000000 00000002 6A62D28C                    off_6A62D28C:               ; Xref 6A66BB846A62D28C 55                     push    ebp6A62D28D 89E5                   mov     ebp,esp6A62D28F 83EC08                 sub     esp,86A62D292 A1CCE3666A             mov     eax,[off_6A66E3CC]6A62D297 83F8FF                 cmp     eax,0FFFFFFFFh6A62D29A 7525                   jnz     loc_6A62D2C16A62D29C A18826786A             mov     eax,[TlsAlloc]6A62D2A1 FFD0                   call    eax6A62D2A3 A3CCE3666A             mov     [off_6A66E3CC],eax6A62D2A8 A1CCE3666A             mov     eax,[off_6A66E3CC]6A62D2AD 83F8FF                 cmp     eax,0FFFFFFFFh6A62D2B0 7505                   jnz     loc_6A62D2B76A62D2B2 E8C9E20300             call    jmp_abort6A62D2B7                    loc_6A62D2B7:               ; Xref 6A62D2B06A62D2B7 E812110000             call    fn_6A62E3CE6A62D2BC E897FFFFFF             call    fn_6A62D2586A62D2C1                    loc_6A62D2C1:               ; Xref 6A62D29A6A62D2C1 B800000000             mov     eax,06A62D2C6 C9                     leave6A62D2C7 C3                     retIHATOOL caused an invalid page fault inmodule COPY OF LIBVLCCORE.DLL at 016f:6a541271.Registers:EAX=6a540000 CS=016f EIP=6a541271 EFLGS=00010246EBX=00000000 SS=0177 ESP=0063fb64 EBP=0063fb8cECX=00000000 DS=0177 ESI=6a540000 FS=40d7EDX=00000000 ES=0177 EDI=00000000 GS=0000Bytes at CS:EIP:89 15 f0 e3 66 6a 75 4c a1 00 b0 77 6a 85 c0 74 Stack dump:00000002 bff8433d bffc9490 76000000 8190fd84 6a540000 00000000 8190fd84 6a540000 00000000 0063fd74 6a541443 8190fd41 bff768f3 bffc94c0 00000000 6A541260                    fn_6A541260:                ; Xref 6A54143E6A541260 55                     push    ebp6A541261 89E5                   mov     ebp,esp6A541263 57                     push    edi6A541264 89CF                   mov     edi,ecx6A541266 56                     push    esi6A541267 89C6                   mov     esi,eax6A541269 53                     push    ebx6A54126A 89D3                   mov     ebx,edx6A54126C 83EC1C                 sub     esp,1Ch6A54126F 85D2                   test    edx,edx6A541271 8915F0E3666A           mov     [off_6A66E3F0],edx6A541277 754C                   jnz     loc_6A5412C56A541279 A100B0776A             mov     eax,[off_6A77B000]6A54127E 85C0                   test    eax,eax6A541280 746E                   jz      loc_6A5412F06A541282 E829A51100             call    fn_6A65B7B06A541287 897C2408               mov     [esp+8],edi6A54128B C744240400000000       mov     dword ptr [esp+4],06A541293 893424                 mov     [esp],esi6A541296 E8E55F0800             call    fn_6A5C72806A54129B 83EC0C                 sub     esp,0Ch6A54129E 89C2                   mov     edx,eax6A5412A0                    loc_6A5412A0:               ; Xref 6A54131C 6A541321 6A5414116A5412A0 83FB03                 cmp     ebx,36A5412A3 0F84CE000000           je      loc_6A5413776A5412A9                    loc_6A5412A9:               ; Xref 6A5413716A5412A9 85DB                   test    ebx,ebx6A5412AB 0F84C6000000           je      loc_6A5413776A5412B1                    loc_6A5412B1:               ; Xref 6A5412F2 6A5413AD 6A5413F36A5412B1 C705F0E3666AFFFFFFFF   mov     dword ptr [off_6A66E3F0],0FFFFFFFFh6A5412BB 8D65F4                 lea     esp,[ebp-0Ch]6A5412BE 89D0                   mov     eax,edx6A5412C0 5B                     pop     ebx6A5412C1 5E                     pop     esi6A5412C2 5F                     pop     edi6A5412C3 5D                     pop     ebp6A5412C4 C3                     ret.data 6A66C000-6A66EFFF IRW, so these should be okay instead of faulting on write:6A62D2A3 A3CCE3666A             mov     [off_6A66E3CC],eax6A541271 8915F0E3666A           mov     [off_6A66E3F0],edx

The two writes at 6A66E3CC and 6A66E3F0 are at the end of the Read/Write .data section, but somehow the loader set the permissions for those addresses to Read-only. Hexing the .text section permissions to enable writing fixed the GPF's and allowed the 2.1.3 Libvlccore to load successfully. This indicates the (KernelEx-modified?) loader is allocating memory incorrectly.

While there are a number of differences (bugs) in the GCC 4.2.8 output of VLC 2.1.3 versus 2.1.2, I haven't been able to find the change that is triggering the problem. I need more (and smaller) examples. Has anyone confirmed that the plug-ins really needed to be UPX'ed? If so, I need to know (some of) which ones do and (some of) which ones don't so I can compare them across versions. Thanks.

Edited April 3, 2014 by jumper

[DougB]

@dencorso: I UPXed each of the individual .EXE and .DLL files in both the program (top) folder and all the subfolders in the plugins folder. Tedious to do without some kind of "global"-type command that repeats an executable (UPX.EXE in this case) in current and subfolders. (There are 24 subfolders under plugins in VLC 2.1.3!)

@jumper: Yes, in my (and loblo's) experience, the plugin folder DLLs do need to be UPXed. For me, when i only compressed the .EXEs and .DLLs in the program (top) folder, it made it past it's own DLLs, but then it choked on a system DLL:

VLC caused an invalid page fault in module KERNEL32.DLL

I initially tried compressing files in the program folder one at a time and then running VLC.EXE. After UPXing only VLC.EXE, i got:

VLC caused an invalid page fault in module LIBVLCCORE.DLL

Then after UPXing LIBVLCCORE.DLL, i got:

VLC caused an invalid page fault in module LIBVLC.DLL

Then after UPXing LIBVLC.DLL, i got:

VLC caused an invalid page fault in module KERNEL32.DLL

at which point i hung it up, until loblo said to UPX the files in the plugins folder. Which worked all the way.

- Doug B.

[MiKl]

Has anyone confirmed that the plug-ins really needed to be UPX'ed? If so, I need to know (some of) which ones do and (some of) which ones don't so I can compare them across versions. Thanks.

Hi Jumper, I just repeated the process and VLC started after I have UPX'ed (in alphabetical order) the plugin folder: video output.

Unfortunately I think that doesn't help much because after that there is only one plugin left - visualisation - containing only three dll's.

I also made a quick test by upx'ing only video_chroma, video_filter and video_output but that didn't worked.

So it may indeed be necessary to process all plugin dll's.

[loblo]

Glad to have you back, loblo!

Thanks.

[loblo]

While there are a number of differences (bugs) in the GCC 4.2.8 output of VLC 2.1.3 versus 2.1.2, I haven't been able to find the change that is triggering the problem. I need more (and smaller) examples. Has anyone confirmed that the plug-ins really needed to be UPX'ed? If so, I need to know (some of) which ones do and (some of) which ones don't so I can compare them across versions. Thanks.

Of the plugins that autoload when VLC starts without argument here, those crash the app if they are not UPXed:

.\plugins\access\libaccess_bd_plugin.dll 98.0 KB

.\plugins\access\libaccess_vdr_plugin.dll 74.5 KB

.\plugins\access\libdshow_plugin.dll 262 KB

.\plugins\access\libfilesystem_plugin.dll 44.5 KB

.\plugins\access\liblibbluray_plugin.dll 1.92 MB

.\plugins\access\libstream_filter_rar_plugin.dll 39.5 KB

.\plugins\access\libzip_plugin.dll 111 KB

.\plugins\audio_filter\libequalizer_plugin.dll 48.5 KB

.\plugins\control\libglobalhotkeys_plugin.dll 37.5 KB

.\plugins\control\libhotkeys_plugin.dll 53.0 KB

.\plugins\demux\libplaylist_plugin.dll 130 KB

.\plugins\gui\libqt4_plugin.dll 10.6 MB

.\plugins\lua\liblua_plugin.dll 290 KB

.\plugins\meta_engine\libtaglib_plugin.dll 1.44 MB

.\plugins\stream_filter\libdash_plugin.dll 692 KB

.\plugins\stream_filter\libhttplive_plugin.dll 519 KB

.\plugins\stream_filter\libsmooth_plugin.dll 59.5 KB

And those don't crash VLC and get loaded fine:

.\plugins\access\libdvdnav_plugin.dll 235 KB

.\plugins\audio_output\libdirectsound_plugin.dll 27.0 KB

.\plugins\audio_output\libwaveout_plugin.dll 30.5 KB

.\plugins\misc\libxml_plugin.dll 1.19 MB

.\plugins\video_output\libdirectdraw_plugin.dll 65.0 KB

.\plugins\stream_filter\librecord_plugin.dll 14.5 KB

[jumper]

This is great, loblo.

The first group all have 32-bit alignment in the .rdata section; the second group, 4-bit alignment. The first group all double-GPF when directly loaded with LoadLibrary, the second group don't.

Changing the reported alignment bits doesn't help, however. Also, the VLC 2.1.2 plugins all load without error no matter what the alignment.

Changing the .text section to be writable or UPXing the problem files both work.... UPXing is still the easiest/best work-around.

[loblo]

This is great, loblo.

The first group all have 32-bit alignment in the .rdata section; the second group, 4-bit alignment. The first group all double-GPF when directly loaded with LoadLibrary, the second group don't.

Changing the reported alignment bits doesn't help, however. Also, the VLC 2.1.2 plugins all load without error no matter what the alignment.

Changing the .text section to be writable or UPXing the problem files both work.... UPXing is still the easiest/best work-around.

Interesting, I have set the .text section of all the VLC 2.1.3 files to be writable and it works as good as UPXing apparently.

It's very easy to do with NW PE Builder in case anyone's interested in using this method, no batch processing possible unlike with the UPX method however.

The files that don't have a problem don't have a writable .text section so it's still very mysterious to me what is going on but it sure is nice to have an alternate solution.

Jumper, if you've got some spare time, could you look into the recent built of executables that crash in kexbases.dll? It seems like a generic issue and it's very annoying. As per faultlog.txt most crash in kexbases.dll at 0177:bfa41cbe and have no apparent missing functions/dependencies in common which seem to exclude a problem with KernelEx inadequate definitions. I can run the affected console programs without crashing in kexbases by profiling them in Dependency Walker, GUI apps fail to start in DW for other (and quite usual for KernelEx only apps) reasons.

Presumably interesting examples:

ffmpeg: both shared and static builds are identically affected. Only ffmpeg.exe and ffprobe.exe crash, ffplay.exe doesn't. All run without crashing from within DW. All files require the UPX or writable .text section fix first. Crashes occur at 0177:bfa41c54 which is slightly different than for most other programs.

http://ffmpeg.zeranoe.com/builds/win32/static/ffmpeg-20140405-git-ec8789a-win32-static.7z

http://ffmpeg.zeranoe.com/builds/win32/shared/ffmpeg-20140405-git-ec8789a-win32-shared.7z

zxtune: both latest (r3000) MINGW and MSVC builds are affected. Earlier builds (r2850) both run fine. Includes GUI and console programs. All console programs run without crash from within DW.

https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/2850/mingw/x86/zxtune_r2850_mingw_x86.zip

https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/2850/windows/x86/zxtune_r2850_windows_x86.zip

https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/3000/mingw/x86/zxtune_r3000_mingw_x86.zip

https://googledrive.com/host/0BzfWZ2kQHJsGZUhTSkRMdjJGYjQ/3000/windows/x86/zxtune_r3000_windows_x86.zip

Edited April 5, 2014 by loblo

[Flasche]

Thanks loblo. I know I already thanked you here, but you deserve it. I found that dragging the vlc folder into UPX (GUIPeX) was the quickest way to get vlc to work. It seems that UPXing would be needed for new programs to run since KernelEx died. May I ask you to post a list loblo of all the programs you got to work with this compression tactic.

[Flasche]

Thanks loblo. I know I already thanked you here, but you deserve it. I found that dragging the vlc folder into UPX (GUIPeX) was the quickest way to get vlc to work. It seems that UPXing would be needed for new programs to run since KernelEx died. May I ask you to post a list loblo of all the programs you got to work with this compression tactic.

Hmm seems to be having a problem. I did the way I described in the description, then I did it with just dlls (uninstalled then reinstalled), but I cant get sound to play. Can't figure out whats wrong.

[Drugwash]

Apologies for breaking the VLC trend here, but a few days ago, using the same UPX trick discovered by loblo, I managed to use the CloudMe application (v1.8.0), uploading files from my Win98SE machine. Synchronisation also seems to work correctly.

There are still a few quirks, probably unfixable:

- the systray menu won't show up so the application must be killed when finished working with it

- file/folder navigation is buggy and requires copy/paste for getting to the desired file/folder

It is mandatory to upgrade the root certificates in order for the application to connect to the cloud server. The certificates can be obtained from uSP3 or downloaded directly from M$ (validation required).

The CloudMe application is built around Qt5 and uses the VC10 and VC11 runtimes as well as a recent SSL library. All of the DLLs and EXEs must be packed with UPX, including those in subfolders. I used no commandline parameters when packing.

That's about all. If you want a free 3GB cloud space, get it, fix it, run it!

(I sincerely hope the above won't be taken as advertising, since I got no truck whatsoever with that cloud storage company or whatever)

[dencorso]

(I sincerely hope the above won't be taken as advertising, since I got no truck whatsoever with that cloud storage company or whatever)

Of course not, rest assured.

[Flasche]

Apologies for breaking the VLC trend here, but a few days ago, using the same UPX trick discovered by loblo, I managed to use the CloudMe application (v1.8.0), uploading files from my Win98SE machine. Synchronisation also seems to work correctly.

There are still a few quirks, probably unfixable:

- the systray menu won't show up so the application must be killed when finished working with it

- file/folder navigation is buggy and requires copy/paste for getting to the desired file/folder

It is mandatory to upgrade the root certificates in order for the application to connect to the cloud server. The certificates can be obtained from uSP3 or downloaded directly from M$ (validation required).

The CloudMe application is built around Qt5 and uses the VC10 and VC11 runtimes as well as a recent SSL library. All of the DLLs and EXEs must be packed with UPX, including those in subfolders. I used no commandline parameters when packing.

That's about all. If you want a free 3GB cloud space, get it, fix it, run it!

(I sincerely hope the above won't be taken as advertising, since I got no truck whatsoever with that cloud storage company or whatever)

NO NO continue please continue. I'm guessing that this program isn't normally supported with KernelEx... Interesting. If there are a lot more programs like this then UPX should get its own thread .

[Drugwash]

(I sincerely hope the above won't be taken as advertising, since I got no truck whatsoever with that cloud storage company or whatever)

Of course not, rest assured.

Thank you, just wanted to be on the safe side. One never knows when their actions (read: words) may be misinterpreted.

Apologies for breaking the VLC trend here, but a few days ago, using the same UPX trick discovered by loblo, I managed to use the CloudMe application (v1.8.0), uploading files from my Win98SE machine. Synchronisation also seems to work correctly.

There are still a few quirks, probably unfixable:

- the systray menu won't show up so the application must be killed when finished working with it

- file/folder navigation is buggy and requires copy/paste for getting to the desired file/folder

It is mandatory to upgrade the root certificates in order for the application to connect to the cloud server. The certificates can be obtained from uSP3 or downloaded directly from M$ (validation required).

The CloudMe application is built around Qt5 and uses the VC10 and VC11 runtimes as well as a recent SSL library. All of the DLLs and EXEs must be packed with UPX, including those in subfolders. I used no commandline parameters when packing.

That's about all. If you want a free 3GB cloud space, get it, fix it, run it!

(I sincerely hope the above won't be taken as advertising, since I got no truck whatsoever with that cloud storage company or whatever)

NO NO continue please continue. I'm guessing that this program isn't normally supported with KernelEx... Interesting. If there are a lot more programs like this then UPX should get its own thread .

Indeed, trying to run that application straight after installing it would result in crash, even on a KernelEx system. My 98SE machine has survived uncounted crashes since Sept.2006 and is still going strong. But nowadays it seems we have to delve deeper.

I've posted the essentials above. Waiting for anybody interested to confirm my findings or post adjacent issues. Ideally we should find out what exactly UPX does to prevent crashes. At first I thought it might me OS version/Subsystem version/Linker version in the exe/dll to make trouble, but then I read about .text sections above and I'm not sure now what the correct answer would be.

[loblo]

May I ask you to post a list loblo of all the programs you got to work with this compression tactic.

As already mentioned in my initial post:

PotPlayer 1.6.46541 which is the current/latest version. Way better than VLC in every way IMO. Supports HEVC & VP9 decoding.

LavFilters 0.59.1 nightly build of 2013-12-16 at http://roy.orz.hm/lavf-w32-nightlies/lavf-my131216-210f2d6.7z. All subsequent builds also crash in kexbases.dll. Supports HEVC & VP9 decoding.

Any Gimp version that has exe/dll crashing up to the current/latest 2.8.10.

Those are the only ones I know for sure but there are certainly many more for you to discover.

Edited April 6, 2014 by loblo

[Flasche]

May I ask you to post a list loblo of all the programs you got to work with this compression tactic.

As already mentioned in my initial post:

PotPlayer 1.6.46541 which is the current/latest version. Way better than VLC in every way IMO. Supports HEVC & VP9 decoding.

LavFilters 0.59.1 nightly build of 2013-12-16 at http://roy.orz.hm/lavf-w32-nightlies/lavf-my131216-210f2d6.7z. All subsequent builds also crash in kexbases.dll. Supports HEVC & VP9 decoding.

Any Gimp version that has exe/dll crashing up to the current/latest 2.8.10.

Those are the only ones I know for sure but there are certainly many more for you to discover.

Thanks. This is very interesting in deed. I think there are a a lot more programs out there that will work with this. Time to experiment.