[Bug 23283] Cannot print my annual income tax return in ElsterFormular (crash)

wine-bugs at winehq.org wine-bugs at winehq.org
Sun Jun 20 15:26:35 CDT 2010


Anastasius Focht <focht at gmx.net> changed:

           What    |Removed                     |Added
                 CC|                            |focht at gmx.net

--- Comment #2 from Anastasius Focht <focht at gmx.net>  2010-06-20 15:26:34 ---

Wine bug unearthed by an "ElsterFormular" application bug ;-)

Prerequisites: vcrun6 and some (free) pdf reader application to use "print
preview" (app internally exports/generates .pdf).

--- quote ---
wine: Unhandled exception 0xc0000409 at address 0x42f6e2 (thread 001c),
starting debugger...
--- quote ---

This exception is caused by the app's internal runtime detecting a stack
corruption (it uses stack security cookies).
Basically after calling shell32.FindExecutableW() the stack got corrupted.
For the interested how stack cookies work:

Annotated app callstack before entering shell32.FindExecutableW():


--- snip app stack ---
003396BC       041CA512    lpFile = "C:\users\focht\Application
003396C0       00000000    lpDirectory = NULL
003396C4       0033970C    lpResult = 0033970C
; lpResult buffer starts here
0033970C       00000000
; stack security cookie
0033980C       5A6E2810
; points to next SEH record
00339810       00339868
; structured exception handler
00339814       00444702
00339818       00000007
; return to caller
0033981C       004167C0
--- snip app stack ---

dlls/shell32/shlexec.c:FindExecutableW -> SHELL_FindExecutable()

SHELL_FindExecutableByOperation() is used to determine the executable to be
launched with certain registered filetype (.pdf extension registered):

--- snip dlls/shell32/shlexec.c ---
static UINT SHELL_FindExecutable(LPCWSTR lpPath, LPCWSTR lpFile, LPCWSTR
                                 LPWSTR lpResult, int resultLen, LPWSTR key,

    if (*filetype)
        /* pass the operation string to SHELL_FindExecutableByOperation() */
        retval = SHELL_FindExecutableByOperation(lpOperation, key, filetype,
command, sizeof(command));

    if (retval > 32)
        DWORD finishedLen;
        SHELL_ArgifyW(lpResult, resultLen, command, xlpFile, pidl, args,
        if (finishedLen > resultLen)
        ERR("Argify buffer not large enough.. truncated\n");
--- snip dlls/shell32/shlexec.c ---

Resulting in -> ""C:\Program Files\Tracker Software\PDF Viewer\PDFXCview.exe"
"%1"" (the pdf viewer I installed for this purpose).
Replacing "%1" -> "C:\users\focht\Application

What happens is that the output buffer (lpResult) of FindExecutableW() caller
will actually contain two strings in argv-style: executable and file name up to
This is wrong - the app buffer should never get the %1 (filename) parameter
(even if it's "invisible" due to null terminator in between) - it only
requested executable name - an unfortunate side effect of Wine's code sharing
at this place.

I already mentioned this Wine bug was unearthed by an application bug.
As you can see in annotated stack snippet, the application didn't bother to
provide what Microsoft suggests for lpResult: MAX_PATH length
Even if Wine fixes the problem by only copying executable path - if the pdf
executable path is long enough, it will most likely also corrupt the stack on

Someone should tell these guys how to write "secure" software:

But what can you expect from people that use german identifiers all over the
place for their classes, functions, variables and the like .. that's pure
coding horror (never heard of industry standards?).
Run the app with WINEDEBUG=+debugstr and see what I mean ...


Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.

More information about the wine-bugs mailing list