ntdll!kifastSystemcallret, SharedUserData!SystemCallStub and search engines…

If I were to pick out ten keywords for my blog I would pick, in no particular order, ASP.net, windbg, sos, debugging, .net exceptions, memory leaks, performance issues, OutOfMemory exceptions, garbage collection, troubleshooting. Those are the things that I think, but I might be wrong, that people who visit my blog are most interested in.

As with most other technical blogs (I think), about half of the traffic to my blog comes from people searching on various search engines, but what really surprised me was what the top search terms are that bring people here, since obviously my keywords are way off :)

1. kifastsystemcallret
2. .net exception types
3. ntdll!kifastsystemcallret
4. 0x800703e9
5. 0xe0434f4d
6. Invalid viewstate
7. tess blog
8. tess fernandez
9. developerinstallation
10. unblock

The 0x800703e9 (exception code for StackOverflow) and 0xe0434f4d (exception code for .net exceptions) I can completely understand, just like invalid viewstate and “.net exception types” since I have written quite a bit about these subjects.

Incidentally, if you got here through a search and you want to see my posts on the topic, check out the post index.

The search for Tess Fernandez is a bit funny, especially since my name is Ferrandez :) so I’m not sure how this blog even comes up as the number 1 choice on live and google for that search term.

kifastsystemcallret

But… what surprised me the most was the overwhelming amount of searches for kifastsystemcallret and ntdll!kifastsystemcallret that brought people here. I even had to stop and think for a moment to try to recall if I had ever written anything on the topic :)

kifastsystemcallret is a return function address for trap frames, similar to sharedUserData!SystemCallStub. That sounds about as interesting as watching paint dry :) but if you’re interested in the details you can read more about it here. What is interesting though is where you see it, and that is probably what gets people searching for it.

If you have a memory dump or break into a live process with windbg, these frames will be on top of the stack, for example in

  11  Id: fb8.268 Suspend: 0 Teb: 7ffaa000 Unfrozen
ChildEBP RetAddr  Args to Child
0199fdf8 7c822124 77e6baa8 00000234 00000000 ntdll!KiFastSystemCallRet
0199fdfc 77e6baa8 00000234 00000000 0199fe40 ntdll!NtWaitForSingleObject+0xc
0199fe6c 77e6ba12 00000234 00009c40 00000000 kernel32!WaitForSingleObjectEx+0xac
0199fe80 791d401f 00000234 00009c40 00000000 kernel32!WaitForSingleObject+0x12
0199fea4 791fdacc 00000000 00000000 80a56bcc mscorsvr!ThreadpoolMgr::WorkerThreadStart+0x3a
0199ffb8 77e66063 000b6da8 00000000 00000000 mscorsvr!ThreadpoolMgr::intermediateThreadProc+0x44
0199ffec 00000000 791fda8b 000b6da8 00000000 kernel32!BaseThreadStart+0x34

So if you debug, this shows up a lot, and something that shows up a lot usually raises a red flag, but rest assured that this is one that you can safely ignore, what is interesting, if anything, is what is below the ntdll!KiFastSystemCallRet and SharedUserData!SystemCallStub.

If you want to know what else you can safely ignore, you might want to have a look at these two posts

• Things to ignore when debugging an ASP.NET hang
• Things to ignore when debugging an ASP.NET Hang - Update for .NET 2.0

What I’ve learned from this is that I am clueless when it comes to search engines :) but hopefully if you came here looking for answers on KiFastSystemCallRet you need to look no longer now.

Laters, Tess