https://bz.apache.org/bugzilla/show_bug.cgi?id=60671
--- Comment #2 from Michael Schlenker <m...@contact.de> --- I had a look at some crash dumps (via procdump) of this issue. In all cases i saw the error seems to be a CloseHandle() on an invalid apr_thread_mutex_t -> handle inside the apr_file object. The code can only create a Critical Section Mutex if APR_HAS_UNICODE_FS is active, but it tries to close a Handle, which is always uninitialized memory for Critial Section Mutexes. The Mutex seems to get destroyed twice, the type is always 0xffffffff = -1, which is the sentinel set by apr_thread_mutex_t when a critical section gets deleted the first time. Microsoft (R) Windows Debugger Version 10.0.10586.567 X86 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [D:\logs\httpd.exe_181120_160002\httpd.exe_181120_161836.dmp] User Mini Dump File with Full Memory: Only application data is available Comment: *** Unhandled exception: C0000008.INVALID_HANDLE' This dump file has an exception of interest stored in it. The stored exception information can be accessed via .ecxr. (d00.fa8): Invalid handle - code c0000008 (first/second chance not available) eax=00000000 ebx=1736d3c0 ecx=00000000 edx=00000000 esi=64697254 edi=17379108 eip=777ac3ec esp=1599f9f0 ebp=1599fa00 iopl=0 nv up ei pl nz ac pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000216 ntdll!NtClose+0xc: 777ac3ec c20400 ret 4 0:255> kb # ChildEBP RetAddr Args to Child 00 1599f9ec 757def8a 64697254 6d018d80 1736c110 ntdll!NtClose+0xc 01 1599fa00 6d018dab 64697254 1599fa20 6d019d99 KERNELBASE!CloseHandle+0x16 02 1599fa0c 6d019d99 17379108 6d016b10 17379108 libapr_1!thread_mutex_cleanup+0x2b [c:\sdk\src\apr-1.6.3\locks\win32\thread_mutex.c @ 35] 03 1599fa20 6d018f94 1736c0d8 17379108 6d018d80 libapr_1!apr_pool_cleanup_run+0x19 [c:\sdk\src\apr-1.6.3\memory\unix\apr_pools.c @ 2620] 04 1599fa34 6d016b3f 17379108 1736d450 1599fa64 libapr_1!apr_thread_mutex_destroy+0x14 [c:\sdk\src\apr-1.6.3\locks\win32\thread_mutex.c @ 133] 05 1599fa44 6cbd1721 1736b258 1736d430 6cbd1756 libapr_1!apr_file_close+0x2f [c:\sdk\src\apr-1.6.3\file_io\win32\open.c @ 503] 06 1599fa50 6cbd1756 00000000 1736c118 1736d2d8 mod_cache_disk!close_disk_cache_fd+0x11 [c:\sdk\src\httpd-2.4.33\modules\cache\mod_cache_disk.c @ 605] 07 1599fa64 6cbe37b6 1736d3c0 009e1048 17d7dc50 mod_cache_disk!remove_entity+0x16 [c:\sdk\src\httpd-2.4.33\modules\cache\mod_cache_disk.c @ 618] 08 1599faf4 6d071eba 17379e00 17d7dc50 1736be38 mod_cache!cache_save_filter+0x9b6 [c:\sdk\src\httpd-2.4.33\modules\cache\mod_cache.c @ 1326] 09 1599fb08 6cbf21fc 17379e00 17d7dc50 171be130 libhttpd!ap_pass_brigade+0x5a [c:\sdk\src\httpd-2.4.33\server\util_filter.c @ 590] 0a 1599fb20 6d071eba 1736be38 17d7dc50 17d7dbc0 mod_headers!ap_headers_output_filter+0x7c [c:\sdk\src\httpd-2.4.33\modules\metadata\mod_headers.c @ 885] 0b 1599fb34 6cc31f20 1736be38 17d7dc50 1736c118 libhttpd!ap_pass_brigade+0x5a [c:\sdk\src\httpd-2.4.33\server\util_filter.c @ 590] 0c 1599fb6c 6d071eba 1736be20 17d7dba8 170381a0 mod_deflate!deflate_out_filter+0x760 [c:\sdk\src\httpd-2.4.33\modules\filters\mod_deflate.c @ 913] 0d 1599fb80 6cb53567 1736be20 17d7dba8 18720020 libhttpd!ap_pass_brigade+0x5a [c:\sdk\src\httpd-2.4.33\server\util_filter.c @ 590] ... 0:255> .frame 02 02 1599fa0c 6d019d99 libapr_1!thread_mutex_cleanup+0x2b [c:\sdk\src\apr-1.6.3\locks\win32\thread_mutex.c @ 35] 0:255> dt data Local var @ 0x1599fa14 Type void* 0x17379108 Void 0:255> dt libapr_1!apr_thread_mutex_t 0x17379108 +0x000 pool : 0x1736c0d8 apr_pool_t +0x004 type : 0xffffffff (No matching name) +0x008 handle : 0x64697254 Void +0x00c section : _RTL_CRITICAL_SECTION -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org For additional commands, e-mail: bugs-h...@httpd.apache.org