runtime: "Failed to start stack walk: 8000ffff" error from ClrStack when reading a core dump file

I created a dump of a .NET Core process on Linux, but cannot get any stack traces from the dump. ClrStack and EEStack both work when attached to the live process, just not when reading the dump. This happens both with the default “minidump with heap” and with a full dump.

Running .NET Core 2.0.5 on Ubuntu 16.04 (x64), kernel 4.4.0-1052.

sudo lldb-3.6 -o "plugin load /opt/dotnet/shared/Microsoft.NETCore.App/2.0.5/libsosplugin.so" -o "setclrpath /opt/dotnet/shared/Microsoft.NETCore.App/2.0.5" -p 1660```
(lldb) createdump -d -f core.%d.full

(clrstack and eestack work here)

Then:

sudo lldb-3.6 -o "plugin load /opt/dotnet/shared/Microsoft.NETCore.App/2.0.5/libsosplugin.so" -o "setclrpath /opt/dotnet/shared/Microsoft.NETCore.App/2.0.5" -core core.1660.full /opt/dotnet/dotnet

(lldb) clrstack
OS Thread Id: 0x0 (1)
Failed to start stack walk: 8000ffff

(lldb) thread select 21
* thread dotnet/coreclr#21: tid = 20, 0x00007f29b912c709 libpthread.so.0`__pthread_cond_timedwait + 297, stop reason = signal SIGABRT
    frame #0: 0x00007f29b912c709 libpthread.so.0`__pthread_cond_timedwait + 297
-> 0x7f29b912c709 <__pthread_cond_timedwait+297>: movq   %rax, %r14
   0x7f29b912c70c <__pthread_cond_timedwait+300>: movl   (%rsp), %edi
   0x7f29b912c70f <__pthread_cond_timedwait+303>: callq  0x7f29b912f1c0            ; __pthread_disable_asynccancel
   0x7f29b912c714 <__pthread_cond_timedwait+308>: movq   0x8(%rsp), %rdi
(lldb) clrstack
OS Thread Id: 0x14 (21)
Unable to walk the managed stack. The current thread is likely not a
managed thread. You can run !threads to get a list of managed threads in
the process
Failed to start stack walk: 80070057

(lldb) eestack -EE
---------------------------------------------
Thread   1
TEB information is not available so a stack size of 0xFFFF is assumed
Current frame:
Child-SP         RetAddr          Caller, Callee
---------------------------------------------
Thread   1
TEB information is not available so a stack size of 0xFFFF is assumed
Current frame:
Child-SP         RetAddr          Caller, Callee
---------------------------------------------
Thread   1
TEB information is not available so a stack size of 0xFFFF is assumed
Current frame:
Child-SP         RetAddr          Caller, Callee
---------------------------------------------
Thread   1
TEB information is not available so a stack size of 0xFFFF is assumed
Current frame:
Child-SP         RetAddr          Caller, Callee

Threads 1 and 21 are both managed threads and ClrStack works on them in the live session. eestack without -EE does show some native frames: eestack.txt. thread backtrace all also works, so I think the dump itself is good.