If broken it is, fix it you should

Using the powers of the debugger to solve the problems of the world - and a bag of chips    by Tess Ferrandez, ASP.NET Escalation Engineer (Microsoft)

ntdll!kifastSystemcallret, SharedUserData!SystemCallStub and search engines...

ntdll!kifastSystemcallret, SharedUserData!SystemCallStub and search engines...

  • Comments 8

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

  • My call stack looks nothing like yours. My application's UI has stopped updating, the call stack looks like this...

    ntdll.dll!_KiFastSystemCallRet@0()

    user32.dll!GetWindowLongA()  + 0x61

    user32.dll!SendMessageA()  + 0x49

    MFC71.dll!CListCtrl::GetItemText(int nItem=0x00000000, int nSubItem=0x01e144a8)

    Basically call to the CListCtrl::GetItemText never returned.

    The nSubItem value should be 1, I'm not sure why the debugger (VS 2003) thinks it is 0x01e144a8.

  • I'm one of those weird people with interest in ntdll!kifastsystemcallret, and I can tell you that this phenomena has nothing to do with dumps or debugging. It's related to a drwatson entry in the event log, in which "ntdll!kifastsystemcallret" is the only character string a normal person finds remotely related to human words, so this is what we type in google search. :)

    If only windows were willing to tell which particular service is failing, instead of babbling about svchost.exe...

  • Charlie,  thanks for the info, very interesting

  • Thanks Tess.  Exactly what I was needing to know.  I am also tracing some events in Dr. Watson log and this was the first discernible line in the stack dump.  

    I guess I'm supposed to read those stack dumps from the bottom up instead of the top down?

  • Im another one of those people with ntdll.KiFastSystemCallRet :D Did some amateur programmining in Delphi, and the program is fine when I let it run slow putting breakpoints in, but when I try to run it without breakpoints it stops responding after a while and the cpu stands at

    ntdll.KiFastSystemCallRet: 7C90E514 C3               ret

  • Yeah, just about whenever you do a stack trace for thread that isn't just crunching data in userspace, you get that first line in the traceback. Maybe they need to add something like !analyze output to the beginning of the DrWatson dump text so that mere users will have some hope of figuring out who/what to blame?

  • UE3-2917_GC-76511_2011.09.02-13.10.57.dmp]

    Пользователь Мини файла дампа: только регистры, стек и участков памяти доступны

    Символ путь поиска: *** *** Недопустимый

    ************************************************** **************************

    * Символ загрузки могут быть недостоверными, не путь поиска символа. *

    * Используйте. Symfix иметь отладчик выбрать путь к символам. *

    * После включения на пути к символам, используйте. Перезагрузки для обновления символа местах. *

    ************************************************** **************************

    Исполняемые п��ти поиска:

    Windows XP версия 2600 (Service Pack 3) MP (2 проки) Бесплатные x86 совместимых

    Продукт: WinNT, люкс: SingleUserTS

    Имя компьютера:

    Debug время сессии: Пт 2 сентября 13:11:00.000 2011 (UTC + 6:00)

    Время работы системы: отсутствует

    Процесс Uptime: 0 дней 0:00:05.000

    .................................................. ..............

    ....

    Этот файл дампа имеет исключением интерес, хранящиеся в нем.

    Хранятся сведения об исключении можно получить доступ через. Ecxr.

    (1240.134c): Нарушение прав доступа - код c0000005 (первый / второй шанс не доступен)

    EAX = 05f30000 EBX = 00589508 ECX = 00000007 EDX = 7c90e514 ESI = 005894e0 EDI = 00589538

    EIP = 7c90e514 ESP = EBP = 0354ec50 0354ec60 IOPL = 0 до пи е, пл Zr па ре пс

    CS = 001B сс = 0023 DS = 0023 ES = 0023 FS = 003B GS = 0000 EFL = 00200246

    *** ОШИБКА: Символ файл не может быть найдено. Дефолт экспортировать символы для ntdll.dll -

    ! NTDLL KiFastSystemCallRet:

    7c90e514 c3 отставке

    ЧТО ЭТО ТАКОЕ?

  • most useless search result on google for kifastsystemcallret.

    but in the meantime the most funny one :)

Page 1 of 1 (8 items)
Leave a Comment
  • Please add 1 and 7 and type the answer here:
  • Post