@TessFerrandez
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. kifastsystemcallret2. .net exception types3. ntdll!kifastsystemcallret4. 0x800703e95. 0xe0434f4d6. Invalid viewstate7. tess blog8. tess fernandez9. developerinstallation10. 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 hangThings 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 отставке
ЧТО ЭТО ТАКОЕ?