unexpected ucrtbase.dll

[P3t3rU5]

What problems are you experiencing?

unexpected ucrtbase.dll when running anything ruby

Steps to reproduce

any ruby executable execution like ruby -v, gem list, etc

What's the output from ridk version?

unexpected ucrtbase.dll

Furthermore, I'm on Windows 11 Pro Insider Preview build 25211.rs_prerelease.220923-1354 and I'm suspecting something changed in latest build

[larskanis]

OK, this is rather unexpected 😄

Which RubyInstaller version did you use? Can you compare 3.0 and 3.1 versions? RubyInstaller-3.1 switched to more modern UCRT runtime, while 3.0 still uses the MSVCRT.

[P3t3rU5]

Didn't even thought of trying other versions
I had some previous versions installed:

• 3.0.1 verion is working
• 3.1.1 is not working
• 3.1.2 is not working

[s00ner]

I'm on the same Windows 11 version and also recently started getting unexpected ucrtbase.dll when running anything ruby.

[ArminG-MSFT]

Hello this is Armin from Microsoft. We encountered the same or at least a very similar issue in our internal compatibility testing. What seems to be the issue is that Ruby is relying on undocumented/unsupported behaviour. It is trying to retrieve a pointer to an internal variable __pioinfo inside urtbase.dll. That itself is not supported, but from our debugging and looking at the code in win32.c it looks like it is doing it by walking back from the ret assembly instruction in _isatty(). But this assumes the ret instruction will be the last instruction in that _isatty().

The issue is that certain optimizations can move function code beyond a ret instruction, so the common/typical instruction path is shorter. And new optimizations we applied to recent ucrtbase.dll builds did exactly that in _isatty(). So it looks like Ruby is now looking at the wrong location and no longer finding __pioinfo.

Short term we'll be rolling out a fix that for this function that undoes this optimization, which should fix this specific error for the many Ruby users in the wild. But it would be great if Ruby can be fixed to not use undocumented behaviour, or perhaps at least be more robust in its function traversal. Note though that at some point we may break it in some way that is not so easily fixed.

The offending code is in win32\win32.c function set_pioinfo_extra.

Feel free to correct me though if our understanding is incorrect.

[MSP-Greg]

@ArminG-MSFT Thank you. Added your comments to https://bugs.ruby-lang.org/issues/18605#note-4

[gonzaloriestra]

@ArminG-MSFT thanks a lot for the detailed explanation. Could you be so kind to let us know once the fix is released?

[ArminG-MSFT]

Tentative will be in about two weeks. I'll provide a build number when available.

Some additional background to explain why the current Ruby behaviour is not very desirable. We at Microsoft use Profile Guided Optimizations, and hence every time we generate a new profile, we can shuffle generated assembly. Add to that shuffle due to internal toolchain behaviour. So the fact that it rarely broke before is remarkable.

We have solved it by making the _isatty entry point a jmp to the actual implementation, and below the jmp non-reachable code that satisfies the Ruby behaviour. If this passes compatibility testing, it will be flighted in about two weeks. That should make sure whatever actual code generation occurs, Ruby will find its sequence.

Of course, at some point, we'll remove this workaround as now every caller of _isatty will have some overhead to satisfy Ruby behaviour. So we should work to get Ruby transferred to something portable. That should also unblock porting ARM64/ARM64EC, so I think we'll have a joint interest here.

[ArminG-MSFT]

Update: The fix will be in build 25235.rs_prerelease or higher. I don't know yet when that will be out publicly.

[ArminG-MSFT]

Build 25236 has just been released. So all blocked can actively search for updates and will get it offered now.

[olifink]

@ArminG-MSFT - I just tried rubyinstaller-devkit-3.1.2-1-x64.exe on Window on Arm (Windows DevKit 2023) with Windows Pro 11 Insider Preview (dev channel) on 25236.rs_prerelease.221028-1618 and still get unexpected ucrtbase.dll trying to run ruby. Shouldn't it run emulated nontheless?

I can confirm same versions (rubyinstaller&windows insider dev) on x64 SurfaceBook works now

[ArminG-MSFT]

Running Ruby on Windows for ARM64 will indeed run emulated, but that has separated generated assembly code which does not contain my fix as it will load the ARM64 native ucrtbase.dll and look for the EC-export (#_isatty vs _isatty). We really need to get Ruby to use ARM64 natively, but let me see what I can do here too.

[ArminG-MSFT]

Update: The issue for ARM64 is of course that Ruby runs emulated, and hence scanning the actual assembly that is executed is never going to yield the expected results. (That is on top of the generic issue that ARM64 does not have a lea-instruction and hence typically will load addresses using a runtime register and the concept itself is tricky.)
But when emulated and using GetProcAddress, one will get the ARM64EC forwarder instead of the actual #_isatty inside ucrtbase.dll. Hence currently Ruby is scanning that forwarder when running emulated. That is great, as that is AMD64 assembly. I managed to insert the dummy sequence there, which unblocks the startup check when Ruby runs on Windows on ARM.

I'll update again when this gets flighted.

[ArminG-MSFT]

Update: The patch for AMD64 emulation on ARM64 will be in 25250.1000.rs_prerelease or higher. I don't know the flight schedule yet.

[ArminG-MSFT]

Update: Build 25252 has just been released. If not offered automatically, actively search for updates will cause it to show.