Outlook 2000 OUTLLIB.DLL

Question

Outlook 2000 OUTLLIB.DLL

Dave D 0

Subject: Outlook 2000 OUTLLIB.DLL

I am investigating repeated Outlook 2000 crashes on Windows 10.

The original OUTLLIB.DLL is version 9.0.0.2711, 5,275,698 bytes.

Windows Application events repeatedly identify:

Exception: 0xC0000005

Fault offset: 0x002D2FF3

Calculated fault address: 0x3A6F2FF3

The corresponding x86 code is:

3A6F2FEE  83 C9 FF   OR ECX,-1
3A6F2FF1  33 C0      XOR EAX,EAX
3A6F2FF3  F2 AE      REPNE SCASB

Two callers reach the same scanning helper:

Caller 1: 0x3A6F318F, using a local buffer at [EBP-0xD8]. An earlier call passes 0x3F (63 decimal) as an argument.

Caller 2: 0x3A6F31DC, using a pointer stored at [EBP-0x34], previously derived from a local buffer at [EBP-0x118].

My question: How can we establish the actual readable capacity of each buffer, determine whether 63 bytes is the appropriate scan bound for either or both callers, and safely replace the effectively unbounded REPNE SCASB operation without changing the function's return semantics?

I would appreciate instruction-level guidance on the correct x86 repair strategy, including handling an invalid input pointer or an unterminated string.

0 comments

2 answers

Your answer

Answer 1

Hi @Dave D

The information shown is not sufficient to establish either buffer’s actual capacity.

[EBP-0xD8] and [EBP-0x118] identify positions within the stack frame, but they do not prove the size or lifetime of the objects placed there. Likewise, the earlier value 0x3F may be a field limit, copy limit, or unrelated argument. It cannot safely be reused as the SCASB bound without tracing that value through the complete caller and callee.

To determine the valid bound, you would need a reproducible crash dump and complete disassembly showing:

the function prologue and full stack-frame layout;
every write into both local regions;
how [EBP-0x34] is derived and whether the pointer can escape its original object;
register values and accessible memory regions at the crash;
the helper’s return-value and flags contract at every call site.

REPNE SCASB is unbounded here because ECX is set to FFFFFFFF. A conceptual replacement would initialize ECX with the verified remaining object capacity, scan for zero, then distinguish “terminator found” from “limit exhausted.” However, preserving semantics requires knowing whether the original helper returns a length, end pointer, Boolean result, or condition-code state.

An invalid pointer cannot be made safe merely by adding a count. It must be rejected before dereferencing, or the caller must be corrected so that it supplies a valid pointer and explicit length. Page-readability checks are not a substitute for object-bound validation, and wrapping the scan in exception handling can conceal corruption.

I would not recommend patching OUTLLIB.DLL. Outlook 2000 is far outside its supported lifecycle, and modifying the DLL can invalidate its integrity and introduce further instability. The practical resolution is to reproduce the issue in a controlled debugger or virtual machine for research, while moving production use to a supported Outlook version. Unsupported Office releases can develop reliability and security problems because fixes and security updates are no longer provided

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more