3.11 apparently builds without error, and 'python' and 'python -m idlelib' appears to start normally, but there is a new problem.
python -m test
raises OS box with 'Debug Assertion Failed!', program python_d.exe,
File minkernal\crts\ucrt\src\time\wcsftime.exe
Line 1184, expression false.
Dismiss box and a few tests run until box repeats and Command Prompt eventually locks.
...test test_idle finished OK once after dismissing box. On retry, test ran OK but CP locked instead of showing new prompt.

3.10 and 3.9 (but not 3.11): compiling show a newish warning.
pythonw.vcxproj -> f:\dev\310\PCbuild\amd64\pythonw_d.exe
pythonw.vcxproj -> f:\dev\310\PCbuild\amd64\pythonw_d.pdb (Full PDB)
f:\dev\310\PCbuild\pythoncore.vcxproj(554,5): warning : A copy of vcruntime140.dll is also required

Does not 3.11 also require this? (wherever it is supposed to be?). Aside from the warning, 3.10 appear to be working normally. There is no error box when starting tests and 50 have run so far without a box.

This sounds more like recent installation changes on your machine. Have
you updated Visual Studio or something like that? Perhaps the debug UCRT
has gone missing.

I'm not aware of any recent compilation changes that would cause this.

Actually, I see this ('Debug Assertion Failed!' in the same spot) every time I try to run the test suite with a debug build, starting yesterday.

Didn't have time to track it down. It _appeared_ to an obscure consequence of this commit:

"""
$ git log timemodule.c
commit a4674f0
Author: Christian Heimes <christian@python.org>
Date: Tue Mar 15 22:55:35 2022 +0200

bpo-40280: Detect presence of time.tzset and thread_time clock (GH-31898)

"""

BTW, the frequency of this new failure mode appears to be vastly increased if running the debug tests with "-j0". For example, the box popping up is reliably the very first sign of life if I run this from the PCBuild directory:

rt -q -d -j0

bpo-46587 added top-level code to "Lib/test/support/init.py" to check whether time.strftime("%4Y") works. Since "Lib/test/libregrtest/setup.py" imports the support module, that code executes before suppress_msvcrt_asserts() is called by setup_tests().

indeed, bisected to

2cf7f86 is the first bad commit
commit 2cf7f86
Author: Christian Heimes <christian@python.org>
Date: Tue Mar 15 11:41:04 2022 +0200

bpo-46587: Skip tests if strftime does not support glibc extension (GH-31873)

Co-authored-by: Victor Stinner <vstinner@python.org>

Ouch, is Python crashes because of an unsupported strftime call?

Christian, yes, but only in a debug build. See Eryk Sun's message a bit above: the machinery to prevent this is already present, but isn't getting called early enough.

Re the 3.9/3.10 warnings: I have not intentionally touched my C install in years. I don't know what Windows' updates do (most recently yesterday) . I presume vcruntime140.dll is on my C: ssd, which has shown no problems. Debug runs w/o -j0 normally take about 18 minutes. After 51 minutes, the 3.10 test run froze CP (as in, had to close with [X] and reopen). Output ends with

"0:51:02 load avg: 0.01 [407/427] test_winconsoleio

Ä^Z"

Ouch, is Python crashes because of an unsupported strftime call?

It's not a crash. It's a CRT error report dialog, which is enabled by default for the _CRT_ASSERT and _CRT_ERROR macros in debug builds. This dialog can be helpful when debugging interactively. It gives a developer the option to abort, retry, or ignore. If a debugger is attached, the retry option breaks into the debugger. I attached a debugger to the test runner to diagnose the problem with format code "%4Y". For example:

    >>> time.strftime('%4Y')
    Debug Assertion Failed!
    [...]
    (Press Retry to debug the application)
    (1a6c.101c): Break instruction exception - code 80000003 (first chance)
    ucrtbased!_Wcsftime_l+0x5af:
    00007ff8`a582b9af cc              int     3

backtrace:

0:000> kc 4
Call Site
ucrtbased!_Wcsftime_l
ucrtbased!_Strftime_l
ucrtbased!strftime
python311_d!time_strftime

locals:

0:000> dv
      _Expr_val = 0n0
         string = 0x00000226`fe38d1c0 ""
       max_size = 0x400
         format = 0x00000226`fe37e7d0 "%4Y"
        timeptr = 0x00000041`c1feeda0
    lc_time_arg = 0x00000000`00000000
         locale = 0x00000000`00000000
  locale_update = class _LocaleUpdate
      format_it = 0x00000226`fe37e7d2 "4Y"
      remaining = 0x400
        lc_time = 0x00007ff8`a5868550
         failed = true
      string_it = 0x00000226`fe38d1c0 ""

resume, with the STATUS_BREAKPOINT (0x80000003) exception handled:

    0:000> gh
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: Invalid format string
    >>> 

For non-interactive testing the report mode needs to be configured to 0 (no report) or to report to stderr. For example:

    >>> msvcrt.CrtSetReportMode(msvcrt.CRT_ERROR, msvcrt.CRTDBG_MODE_FILE)
    4
    >>> msvcrt.CrtSetReportFile(msvcrt.CRT_ERROR, msvcrt.CRTDBG_FILE_STDERR)
    18446744073709551615
    >>> os.abort()
    abort() has been called

For time.strftime('%4Y'), the source of the report is _VALIDATE_RETURN(false, EINVAL, 0) in _Wcsftime_l(). This macro includes an _ASSERT_EXPR(expr, msg) check. In a debug build, this calls _CrtDbgReportW(_CRT_ASSERT, ...) if the expression is false. If the latter returns 1 (retry), the __debugbreak() intrinsic is called to break into the debugger. To suppress the dialog, either temporarily set the CRT_ASSERT report mode to 0, or set it to report to stderr. For example:

    >>> msvcrt.CrtSetReportMode(msvcrt.CRT_ASSERT, msvcrt.CRTDBG_MODE_FILE)
    4
    >>> msvcrt.CrtSetReportFile(msvcrt.CRT_ASSERT, msvcrt.CRTDBG_FILE_STDERR)
    18446744073709551615

    >>> time.strftime('%4Y')
    minkernel\crts\ucrt\src\appcrt\time\wcsftime.cpp(1163) : Assertion failed: false
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: Invalid format string

I think this is also a good enough reason to switch the GitHub CI back to a debug build, rather than release, so that assert failures are caught before they get merged. This is not the first time it's happened.

New changeset d190a93 by Christian Heimes in branch 'main':
bpo-47037: Don't test for strftime('%4Y') on Windows (GH-31945)
d190a93

I recompiled, retested, and all tests are ok, with no unexpected box. Thank you all.

The vcruntime warnings are also gone, so I will chalk them up to a onetime glitch.

The main entry point for python[_d].exe should support a command-line -X option or environment variable that suppresses Windows error/assert/warn reporting, or redirects it to stderr in verbose mode. This would be useful to simplify everyone's automated testing. It should require opting in, both for backward compatibility and also because the dialogs are useful for interactive testing.

New changeset d0a91bd by Steve Dower in branch 'main':
bpo-47037: Test debug builds on Windows in CI so that native assertions are noticed sooner (GH-31965)
d0a91bd