Visual Studio 2019 hanging in cout/printf

Tyler 1

When debugging in Visual Studio 2019, any time my program attempts to cout or print it causes the debugger to stall infinitely. If I pause the debugger and look at the main thread, it will always be in 'ucrtbased.dll!write_text_ansi_nolock' once it gets stalled.

When I run the built exe on it's own, it prints to console perfectly fine. The stalling happens while the application is single threaded, just trying to console print out a single line of text with no variables.

How can I fix this, or look inside the above DLL to see what is happening?

David Lowndes 4,711 Reputation points

2021-10-10T18:23:23.977+00:00

Clearly this isn't normal behaviour, so do you have a small example that will allow someone to reproduce it?
RLWA32 40,286 Reputation points

2021-10-10T18:33:31.257+00:00

Also, what version of VS2019 are you using? Is it the latest one - 16.11.4?
Tyler 1 Reputation point

2021-10-11T02:26:37.467+00:00

I am using VS version 16.11.4, yes.

Reproduction is hard, because if I spin up a new hello world project, the behavior doesn't occur. With my current project the appearance of the problem seems to be inconsistent. Sometimes it happens and sometimes it doesn't even when the things I'm changing aren't related to printing. I could post the code if folks are curious but it is about 3 objects deep to be viable.

So is there a way to step into that dll, or any reference that will explain what 'write_text_ansi_nolock' is? Google isn't showing anything.
RLWA32 40,286 Reputation points

2021-10-11T08:03:46.3+00:00

VS2019 installed the source for the ucrt as part of the Windows SDK. In my VS2019 the function write_text_ansi_nolock is located in "C:\Program Files (x86)\Windows Kits\10\Source\10.0.19041.0\ucrt\lowio\write.cpp".

You can step into this function using the VS debugger with the following steps.

Disable "Just My Code" in debugging options -

Step into your application, open the ucrt source file and set a breakpoint in the write_text_ansi_nolock function. The VS debugger will show the breakpoint cannot be currently hit.

Go to the modules pane and select ucrtbased.dll

Right click and select "Load Symbols". The debugger should load the symbol file and the modules pane should change to -

The breakpoint should then change status and show that it will be hit when debugging continues.
Minxin Yu 10,031 Reputation points Microsoft Vendor

2021-10-11T08:35:42.433+00:00

Please check if there is a out of bounds problem in your program.

Tyler 1

Thanks, after installing the sdk and allowing the debugger to enter external not my code, I was able to catch where it was going. After changing some unrelated things, the problem is now back:

// hang is in ostream standard header - line 743
    if (!_Ok) {
        _State |= ios_base::badbit;
    } else { // state okay, insert
        _TRY_IO_BEGIN
        if ((_Ostr.flags() & ios_base::adjustfield) != ios_base::left) {
            for (; 0 < _Pad; --_Pad) { // pad on left
                if (_Traits::eq_int_type(_Traits::eof(), _Ostr.rdbuf()->sputc(_Ostr.fill()))) {
                    _State |= ios_base::badbit; // insertion failed, quit
                    break;
                }
            }
        }
    .//this is the next line to be executed when I pause the program
        if (_State == ios_base::goodbit && _Ostr.rdbuf()->sputn(_Val, _Count) != _Count) {
            _State |= ios_base::badbit;
        }

Tyler 1 Reputation point

2021-10-17T21:46:52.863+00:00

Why might an out of bounds cause soft lock failure in console output instead of throwing a straight out of bounds exception?
David Lowndes 4,711 Reputation points

2021-10-17T22:16:57.357+00:00

Because it may write somewhere that's not protected, but instead causes weird behaviour.
If you're not already, try building your debug build with the run-time checks (/RTC options) or AddressSanitizer (ASAN) enabled to see if they find any issues.
Also static analysis using the code analysis features in VS, or a 3'rd party tool such as the excellent PVS-Studio may find problems.
Minxin Yu 10,031 Reputation points Microsoft Vendor

2021-10-19T09:16:15.473+00:00

I am afraid it is hard to find out the error. It will be better to have a a minimal reproducible example to know what goes wrong.

6 answers

Abraham Martin 11 Reputation points

2022-11-28T15:53:15.203+00:00

For what it's worth, I managed to solve this closing VS removing the .vs folder and running VS again. Other times it just stopped the same way it appeared: no code changes, no build, just one debugging session is ok, the next one it stops in the 1st printf. It happens with boost calls to (stream_type::write() -> logging system) too, so I suspect "someone" (SO, antivirus?) is not letting VS to write anything out... just guessing.

It happens to me in visual studio 2022 too (using 2019 compilers, I have both VS installed).
Please sign in to rate this answer.

2 people found this answer helpful.

0 comments No comments
Sign in to comment
Justin Ferguson 5 Reputation points

2023-03-28T21:54:36.4766667+00:00

I've had this problem intermittently for years across multiple versions of Visual Studio-- its never in a clean-cut example which makes it hard to reproduce and/or report. I've not looked at what's occurring at an assembly level, but its always in a printf/std::cout et al.

To fix it temporarily, that is to step past the problem until it crops up again-- reboot. To remedy the issue apparently permanently do as suggested by Abraham and delete the .vs folder in the solutions parent directory then restart visual studio.
Please sign in to rate this answer.

1 person found this answer helpful.

0 comments No comments
Sign in to comment
Dan Honeycutt 1 Reputation point

2022-09-19T15:31:15.617+00:00

Has anything more developed on this issue? I have the same problem. My version:

Microsoft Visual Studio Community 2022 (64-bit) - Current
Version 17.2.6

Thanks for any help.
Dan Honeycutt
Please sign in to rate this answer.
Minxin Yu 10,031 Reputation points Microsoft Vendor

2022-09-20T01:34:05.09+00:00

Can you provide a minimal reproducible example?

Tyler 1 Reputation point

2022-09-20T17:57:05.7+00:00

I never did figure out exactly what was causing it but when I cleaned up my multithreading behavior, the problem went away. Something I was doing wasn't thread safe and the debugger would get stuck on it.

So my only advice would be to double check that everything you are doing is 100% thread safe.

Dan Honeycutt 1 Reputation point

2022-09-21T13:26:10.297+00:00

The problem is intermittent. I may work for several hours before the problem shows up, or it might arise in five or ten minutes. I don't know of a code snippet where it will for sure happen. I can tell you this, once it hangs it will then hang on any attempt to use cout. I get going again by shutting down and restarting Visual Studio.

Dan Honeycutt 1 Reputation point

2022-09-21T13:28:35.78+00:00

Ok, thanks. I thought I was thread safe but I'll look further.

Dan Honeycutt 1 Reputation point

2022-09-22T16:15:24.097+00:00

FWIW when it hangs the Debug (Solution Configuration), x64 (Solution Platforms), Thread and Stack boxes all go grey.
When I stop debugging the Debug and x64 boxes come back on.
When I start debugging again Debug and x64 go grey, Thread and Stack boxes come on.
Debug works normally till I hit a cout when it again hangs and all boxes go grey.
Sign in to comment
Minxin Yu 10,031 Reputation points Microsoft Vendor

2023-03-29T05:49:36.12+00:00

delete the .vs folder in the solutions parent directory then restart visual studio.

It is recommended that the problem be reported to the Developer Community. And it would be helpful to provide a minimal reproducible example.
Please sign in to rate this answer.

0 comments No comments
Sign in to comment
Igor Polkovnikov 0 Reputation points

2023-04-17T23:51:48.6833333+00:00

I have the same. VC2022. It hangs in KernelBase WriteFile. After removing .vs it run at least twice fine. Version 17.2.6, x86, Debug
Please sign in to rate this answer.

0 comments No comments
Sign in to comment