The world's slowest RET instruction

Date:	January 3, 2006 / year-entry #6
Tags:	code
Orig Link:	https://blogs.msdn.microsoft.com/oldnewthing/20060103-01/?p=32803
Comments:	4
Summary:	Occasionally, somebody will ask I'm debugging a hang, and I see that many threads are stuck at a RET instruction. When I try to trace one instruction from that thread, the trace breakpoint never fires. It's as if the RET instruction itself is wedged! I've found the world's slowest RET instruction. (A common variation on...

*DISCLAIMER: I DO NOT OWN THIS CONTENT. If you are the owner and would like it removed, please contact me. The content herein is an archived reproduction of entries from Raymond Chen's "Old New Thing" Blog (most recent link is here). It may have slight formatting modifications for consistency and to improve readability.

WHY DID I DUPLICATE THIS CONTENT HERE? Let me first say this site has never had anything to sell and has never shown ads of any kind. I have nothing monetarily to gain by duplicating content here. Because I had made my own local copy of this content throughout the years, for ease of using tools like grep, I decided to put it online after I discovered some of the original content previously and publicly available, had disappeared approximately early to mid 2019. At the same time, I present the content in an easily accessible theme-agnostic way.

The information provided by Raymond's blog is, for all practical purposes, more authoritative on Windows Development than Microsoft's own MSDN documentation and should be considered supplemental reading to that documentation. The wealth of missing details provided by this blog that Microsoft could not or did not document about Windows over the years is vital enough, many would agree an online "backup" of these details is a necessary endeavor. Specifics include:

A "redesign" after 2019 erased thousands of user's comments from previous years. As many have stated, the comments are nearly as important as the postings themselves. The archived copies of the postings contained here retain the original comments.
The blog has changed domains many times and the urls have otherwise been under constant change since 2003. Even when proper redirection has been set up for those links, redirection only works for a limited period of time. For example, all of the internal blog links that were valid in early 2019, were broken by 2020 without proper redirection.
The blog has been under constant re-design and re-theming since its inception. It is downright irritating to deal with a bogged-down site experience as the result of the latest visual themes designed for cell-phone browsers. As of this writing, it is cumbersome to navigate titles with only 10 entries per page. While it is nice that the official site has a search feature, searching using this index (with all titles on a single page) is much quicker (CTRL-F in most browsers).

schwiet says:

January 4, 2006 at 2:49 am

And to think to think of all the time I spent optimizing away the ‘ret’s by making my funtions extra long and convoluted… doh!

Neil says:

January 4, 2006 at 5:15 pm

Great. Now all I need to know is how to kernel debug a machine without a COM port which only hangs when display power saving is active…

1394 says:

January 4, 2006 at 10:29 pm

…… AAARRRRGGGHHHHH.

I wanted to submit this as

Name: 1394

Comments:

i.e., no COM. But your blog wouldn’t allow it. Comments are REQUIRED. Spoils the pun.

BryanK says:

January 10, 2006 at 11:57 am

Ran into this today — SQL server 2000 SP4 logged an error 17883 (UMS context <whatever> appears to be non-yielding, on scheduler <whatever>) while the server was having a bunch of other issues. (TCP connections were timing out, local file access was being either really slow or failing altogether, etc., etc. — I now suspect the hardware; this server is several years old.) When I first saw the error, I suspected SQL, but see below.

When SQL 2000 logs this error, it also writes out a mini-dump file. I loaded this file into windbg, and it appeared that the OS thread that was running the SQL fiber that didn’t yield was actually sitting at a "ret" instruction inside ZwReadFile in kernel32. I eventually remembered this posting, and figured out that SQL probably wasn’t the cause, just another symptom of whatever the problem was. That leaves hardware as probably the only other option, I think.

The problem did clear up a couple minutes later, not that that’s any relief if it happens again… but oh well.

The world’s slowest RET instruction