Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I could not yet produce the backtrace (it is a bit complex for me).
Nevertheless, during my attempt to do it, I had to run apache as a standalone application (httpd -X) and not as a service.
In this context there is NO crash: the soap call all succeed.
Maybe it helps.

I think I managed to produce the backtrace.
Can't see how to attach it to the ticket...

You can probably just put it into a comment. If you feel it may be too long then a pastebin or gist or something like that is fine too.

This bug report was initiated at Apachelounge:
https://www.apachelounge.com/viewtopic.php?p=35105#35105

I tried to reproduce it with the same config, but did not succeed. The Soap login went just fine with PHP 7.1.3 TS x64, running as mod_php under Apache 2.4.25 Win64 VC14.

Here is the info I think useful from backtrace:

PHP_SOAP!SDL_DESERIALIZE_STRING+11In httpd__PID__15704__Date__03_30_2017__Time_10_18_20AM__988__Second_Chance_Exception_C0000005.dmp the assembly instruction at php_soap!sdl_deserialize_string+11 in c:\php\ext\php_soap.dll from The PHP Group has caused an access violation exception (0xC0000005) when trying to read from memory location 0x755b747c on thread 10

php_soap!sdl_deserialize_string+11 
php_soap!get_sdl_from_cache+171 
php_soap!get_sdl+382 
php_soap!zim_SoapClient_SoapClient+b78 
php7ts!ZEND_DO_FCALL_SPEC_RETVAL_UNUSED_HANDLER+d2 
php7ts!execute_ex+64 
php7ts!zend_execute+1d1 
php7ts!zend_execute_scripts+13e 
php7ts!php_execute_script+4f8 
php7apache2_4!php_handler+635 
libhttpd!ap_run_handler+35 
libhttpd!ap_invoke_handler+110 
libhttpd!ap_internal_redirect_handler+29a 
libhttpd!ap_process_request+17 
libhttpd!ap_byterange_filter+1533 
libhttpd!ap_run_process_connection+35 
libhttpd!ap_process_connection+45 
libhttpd!ap_run_generate_log_id+3d9a 
kernel32!BaseThreadInitThunk+d 
ntdll!RtlUserThreadStart+1d

Thanks for the backtrace. I'd suspect there might be something with the cached WSDL stuff like accessing the cache generated by a different PHP version. Unfortunately it's hard to say more without a reproduce case, could please a self contained reproducer be provided?

Thanks.

Good catch !
At some point I cleaned this cache to test, I guess I did not do it well because this morning, cleaning it again and changing the soap cache directory in php.ini to a brand new location I was pleased to see it work perfectly.
Thanks and sorry for the 'false' bug.

Not a bug.