.NET Core Runtime doesn't match available SDK versions to source SOS.DLL for WinDbg

I have a DMP from an application running on my system. This is a .NET Core application. I'm trying to use WinDbg to look at memory issues. From reading around it appears that I need to get the SOS.DLL file that matches the runtime used and it appears a lot harder than expected.

The application appear to be running on a runtime on my PC that does not match a released SDK:

WinDbg: lmDvmcoreclr shows

Loaded symbol image file: coreclr.dll
    Image path: C:\Program Files\WindowsApps\Microsoft.NET.CoreRuntime.2.2_2.2.27404.2_x86__8wekyb3d8bbwe\coreclr.dll
    Image name: coreclr.dll
    Browse all global symbols  functions  data
    Timestamp:        Tue Jan 22 18:40:54 2019 (5C47AA06)
    CheckSum:         004573F9
    ImageSize:        00460000
    File version:     4.6.27322.1
    Product version:  4.6.27322.1

I download the SDKs from https://dotnet.microsoft.com/download/dotnet-core/2.2 to try and find a matching coreclr.dll so I can use the SOS.dll for it.

SDK 2.2.3 -> build 27414

SDK 2.2.2 -> build 27317

So this 4.6.27322.1 appears to be a release that is somehow on my system as between these builds.

Any ideas how this can happen and how I can get the SOS.DLL for it?

To give an example of the issue I am really showing (which is making me believe I should get the exact SOS.DLL), it is this when I try and use SOS:

0:000> .loadby sos coreclr
0:000> 
0:000>  !dumpheap -stat
PDB symbol for coreclr.dll not loaded
Failed to load data access module, 0x80131c4f
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
            2) the file mscordaccore.dll that matches your version of coreclr.dll is
                in the version directory or on the symbol path
            3) or, if you are debugging a dump file, verify that the file 
                mscordaccore_<arch>_<arch>_<version>.dll is on your symbol path.
            4) you are debugging on supported cross platform architecture as 
                the dump file. For example, an ARM dump file must be debugged
                on an X86 or an ARM machine; an AMD64 dump file must be
                debugged on an AMD64 machine.

You can also run the debugger command .cordll to control the debugger's
load of mscordaccore.dll.  .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.

If you are debugging a minidump, you need to make sure that your executable
path is pointing to coreclr.dll as well.

Thanks