[Bug 44811] BattlEye 'BEDaisy' kernel service crashes on unimplemented function ntoskrnl.exe._chkstk
wine-bugs at winehq.org
wine-bugs at winehq.org
Sun Mar 25 10:26:37 CDT 2018
https://bugs.winehq.org/show_bug.cgi?id=44811
Anastasius Focht <focht at gmx.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://static.tibia.com/dow
| |nload/Tibia_Setup.exe
Keywords| |download, obfuscation
CC| |focht at gmx.net
Summary|BattlEye 'BEDaisy' kernel |BattlEye 'BEDaisy' kernel
|service requires _chkstk |service crashes on
|implementation. |unimplemented function
| |ntoskrnl.exe._chkstk
--- Comment #3 from Anastasius Focht <focht at gmx.net> ---
Hello folks,
it seems the usage of this API was introduced in some very recent BattlEye
update.
Maybe because of:
http://www.osronline.com/showThread.cfm?link=47461
* very large structures on stack in driver code
* driver linked with /Ge or /Gs0 flags
--- snip ---
...
007c:Call driver init 0x78d000
(obj=0x11cb90,str=L"\\Registry\\Machine\\System\\CurrentControlSet\\Services\\BEDaisy")
007c:trace:seh:raise_exception code=80000100 flags=1 addr=0x7bc648d0
ip=7bc648d0 tid=007c
007c:trace:seh:raise_exception info[0]=0078d17a
007c:trace:seh:raise_exception info[1]=0078d140
007c:trace:seh:call_vectored_handlers calling handler at 0x7ec15239
code=80000100 flags=1
007c:trace:seh:call_vectored_handlers handler at 0x7ec15239 returned 0
007c:trace:seh:call_stack_handlers calling handler at 0x7bcb203d code=80000100
flags=1
007c:Call KERNEL32.UnhandledExceptionFilter(0065f7a4) ret=7bcb2078
wine: Call from 0x7bc648d0 to unimplemented function ntoskrnl.exe._chkstk,
aborting
--- snip ---
Also refining the summary to be more precise. We already have a '_chkstk' in
'ntdll'.
See bug 28274 ("Multiple 64-bit applications crash due to unimplemented
function kernel32.dll.__chkstk (IE8, Debugging Tools for Windows)") which
introduced it.
--- quote ---
Stupid question, but can't we provide a bigger stack size by default?
--- quote ---
The stack size is not the point here.
Wine loader takes the app requirements into account.
https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/virtual.c#l1927
--- snip ---
1927 NTSTATUS virtual_alloc_thread_stack( TEB *teb, SIZE_T reserve_size, SIZE_T
commit_size, SIZE_T *pthread_size )
1928 {
1929 struct file_view *view;
1930 NTSTATUS status;
1931 sigset_t sigset;
1932 SIZE_T size, extra_size = 0;
1933
1934 if (!reserve_size || !commit_size)
1935 {
1936 IMAGE_NT_HEADERS *nt = RtlImageNtHeader(
NtCurrentTeb()->Peb->ImageBaseAddress );
1937 if (!reserve_size) reserve_size =
nt->OptionalHeader.SizeOfStackReserve;
1938 if (!commit_size) commit_size =
nt->OptionalHeader.SizeOfStackCommit;
1939 }
1940
1941 size = max( reserve_size, commit_size );
1942 if (size < 1024 * 1024) size = 1024 * 1024; /* Xlib needs a large
stack */
1943 size = (size + 0xffff) & ~0xffff; /* round to 64K boundary */
1944 if (pthread_size) *pthread_size = extra_size = max( page_size,
ROUND_SIZE( 0, *pthread_size ));
...
1956 /* setup no access guard page */
1957 set_page_vprot( view->base, page_size, VPROT_COMMITTED );
1958 set_page_vprot( (char *)view->base + page_size, page_size,
1959 VPROT_READ | VPROT_WRITE | VPROT_COMMITTED |
VPROT_GUARD );
1960 mprotect_range( view->base, 2 * page_size, 0, 0 );
...
1980 /* note: limit is lower than base since the stack grows down */
1981 teb->DeallocationStack = view->base;
1982 teb->Tib.StackBase = (char *)view->base + view->size;
1983 teb->Tib.StackLimit = (char *)view->base + 2 * page_size;
1984 done:
1985 server_leave_uninterrupted_section( &csVirtual, &sigset );
1986 return status;
1987 }
--- snip ---
Dump of 'BEDaisy.sys' PE header:
--- snip ---
...
->File Header
Machine: 0x014C (I386)
NumberOfSections: 0x0006
TimeDateStamp: 0x5AA25C8F (GMT: Fri Mar 09 10:06:07 2018)
PointerToSymbolTable: 0x00000000
NumberOfSymbols: 0x00000000
SizeOfOptionalHeader: 0x00E0
Characteristics: 0x0102
(EXECUTABLE_IMAGE)
(32BIT_MACHINE)
->Optional Header
Magic: 0x010B (HDR32_MAGIC)
MajorLinkerVersion: 0x0E
MinorLinkerVersion: 0x00 -> 14.00
SizeOfCode: 0x00008C00
SizeOfInitializedData: 0x00002400
SizeOfUninitializedData: 0x00000000
AddressOfEntryPoint: 0x0000D000
BaseOfCode: 0x00001000
BaseOfData: 0x0000A000
ImageBase: 0x00400000
SectionAlignment: 0x00001000
FileAlignment: 0x00000200
MajorOperatingSystemVersion: 0x000A
MinorOperatingSystemVersion: 0x0000 -> 10.00
MajorImageVersion: 0x000A
MinorImageVersion: 0x0000 -> 10.00
MajorSubsystemVersion: 0x0006
MinorSubsystemVersion: 0x0001 -> 6.01
Win32VersionValue: 0x00000000
SizeOfImage: 0x00105000
SizeOfHeaders: 0x00000400
CheckSum: 0x00106ECF
Subsystem: 0x0001 (NATIVE)
DllCharacteristics: 0x01C0
SizeOfStackReserve: 0x00100000
SizeOfStackCommit: 0x00001000
SizeOfHeapReserve: 0x00100000
SizeOfHeapCommit: 0x00001000
LoaderFlags: 0x00000000
NumberOfRvaAndSizes: 0x00000010
--- snip ---
SizeOfStackReserve = 0x00100000
SizeOfStackCommit = 0x00001000
SizeOfHeapReserve = 0x00100000
These values are pretty much reasonable defaults.
Anyway, unlike Windows there is no need to explicitly "page in" uncommitted
stack pages via __chkstk().
Wine doesn't implement dynamic stack growth using "moving" PAGE_GUARD.
Some nice blog entry with pictures to illustrate how thread stacks work in
general:
https://peteronprogramming.wordpress.com/2016/08/10/crashes-you-cant-handle-easily-2-stack-overflows-on-windows/
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.
More information about the wine-bugs
mailing list