| Groups | Blog | Home |
dotnet clr : Problem in module mscorwks
Hi all,
I have a big problem. I have a console applciation that has a thread inside. No Console.xx is done inside the thread. Sometime (once every 4/6 hours) tha appllication crash without even throwing any .net exception and I cannot debug it even if I run it in debug mode in VS2005. In the event viewer I get this log entry Faulting application Trk.exe, version 1.0.0.0, faulting module mscorwks.dll, version 2.0.50727.42, fault address 0x001057eb. I've read somewhere about an hotfix for the mscorwks.dll but I dunno If it apply to this and where to get it. Any help is appreciated. Regards
Hi Cristian,
I would recommend you to use windbg to run your application, then when this exception is generated in the CLR windbg will break the application. Then you may input "k" command to examine the call stack of this exception. Please refer to my blog entry below for more details of setting up windbg for debugging crash: "How to debug application crash/hang in production environment?" http://blogs.msdn.com/msdnts/archive/2006/11/24/how-to-debug-application-cra sh-hang-in-production-environment.aspx You may paste your call stack here for analysis. If you find an access violation in the mscorwks!SecurityConfig::GetCacheEntry function, I assume you have got the same problem as the one below, you may give the hotfix a try: http://support.microsoft.com/kb/913384/en-us Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
this is what i got
(3650.338c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000066 ebx=00000000 ecx=0662e1d4 edx=04582d00 esi=00000001 edi=012c6a1c eip=79f757eb esp=03dbfeb0 ebp=012c6a24 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206 mscorwks!WKS::gc_heap::mark_object_simple1+0x280: 79f757eb 0fb708 movzx ecx,word ptr [eax] ds:0023:00000066=???? 0:011> k ChildEBP RetAddr 03dbfed8 79f11b80 mscorwks!WKS::gc_heap::mark_object_simple1+0x280 03dbff00 7a0c0398 mscorwks!WKS::gc_heap::mark_object_simple+0x1b0 03dbff30 7a0c596e mscorwks!WKS::gc_heap::c_drain_mark_list+0xa1 03dbff8c 7a0c604c mscorwks!WKS::gc_heap::c_mark_phase+0x138 03dbffa0 7a0c62b9 mscorwks!WKS::gc_heap::gc1+0x61 03dbffb4 7a0c635b mscorwks!WKS::gc_heap::gc_thread_function+0x105 03dbffb8 77e64829 mscorwks!WKS::gc_heap::gc_thread_stub+0x7c 77e63e6f 18a164ec KERNEL32!BaseThreadStart+0x34 WARNING: Frame IP not in any known module. Following frames may be wrong. 77e63e6f 00000000 0x18a164ec I have the debugger still attached, and I'll leave it that way till the problem is solved!!! I'm waiting for a replay in what to do to understeand this problem!!! Thanks a lot [quoted text, click to view] ""Jeffrey Tan[MSFT]"" wrote:
> Hi Cristian, > > I would recommend you to use windbg to run your application, then when this > exception is generated in the CLR windbg will break the application. Then > you may input "k" command to examine the call stack of this exception. > Please refer to my blog entry below for more details of setting up windbg > for debugging crash: > "How to debug application crash/hang in production environment?" > http://blogs.msdn.com/msdnts/archive/2006/11/24/how-to-debug-application-cra > sh-hang-in-production-environment.aspx > > You may paste your call stack here for analysis. If you find an access > violation in the mscorwks!SecurityConfig::GetCacheEntry function, I assume > you have got the same problem as the one below, you may give the hotfix a > try: > http://support.microsoft.com/kb/913384/en-us > > Thanks. > > Best regards, > Jeffrey Tan > Microsoft Online Community Support > ================================================== > Get notification to my posts through email? Please refer to > http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif > ications. > > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues > where an initial response from the community or a Microsoft Support > Engineer within 1 business day is acceptable. Please note that each follow > up response may take approximately 2 business days as the support > professional working with you may need further investigation to reach the > most efficient resolution. The offering is not appropriate for situations > that require urgent, real-time or phone-based interactions or complex > project analysis and dump analysis issues. Issues of this nature are best > handled working with a dedicated Microsoft Support Engineer by contacting > Microsoft Customer Support Services (CSS) at > http://msdn.microsoft.com/subscriptions/support/default.aspx. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. >
This is the output of !VerifyHeap
0:011> !VerifyHeap -verify will only produce output if there are errors in the heap object 012c6a14: bad member 04582d00 at 012c6a1c curr_object : 012c6a14 Last good object: 012c68a4 ---------------- I had some other test. My app work more or less like this Console Program(Main Thread) 1 Working Thread 1 Update Internal Message List 2 lock Thread Message List and read it Update Internal Message List 3 write backed up messages and go to 1 Update Internal Message List The bug seems to be in the management of those strings, but can't understand why. I think the bug is here since if I disable the thread message list the application never crash. While waiting for a reply I'll try to go deeply into this Thanks and regards Cristian Mori [quoted text, click to view] ""Jeffrey Tan[MSFT]"" wrote:
> Hi Cristian, > > I have found a lot of similar errors and stack traces in our internal > database. It looks like some type of corruption in the managed heap of CLR, > which is somewhat tough to debug. I would recommend you to use the > following command to verify the managed heap: > > .load sos > !VerifyHeap > > Please paste the heap verification output here. Thanks. > > If you failed to find sos.dll, please feel free to article below to > understand how to load sos.dll: > "Bugslayer: SOS: It's Not Just an ABBA Song Anymore" > http://msdn.microsoft.com/msdnmag/issues/03/06/Bugslayer/ > > Thanks. > > Best regards, > Jeffrey Tan > Microsoft Online Community Support > ================================================== > Get notification to my posts through email? Please refer to > http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif > ications. > > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues > where an initial response from the community or a Microsoft Support > Engineer within 1 business day is acceptable. Please note that each follow > up response may take approximately 2 business days as the support > professional working with you may need further investigation to reach the > most efficient resolution. The offering is not appropriate for situations > that require urgent, real-time or phone-based interactions or complex > project analysis and dump analysis issues. Issues of this nature are best > handled working with a dedicated Microsoft Support Engineer by contacting > Microsoft Customer Support Services (CSS) at > http://msdn.microsoft.com/subscriptions/support/default.aspx. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. >
Hi Cristian,
Can you save a dump of this exception and then provide a way for me to download? You may use .dump command to get this done in windbg. Most of time managed heap corruptions were coming from some bad PInvokes to some native APIs. You may get a look at: ".NET Crash: Managed Heap Corruption calling unmanaged code" http://blogs.msdn.com/tess/archive/2006/02/09/528591.aspx and "Debugging Whidbey Remoting AccessViolation Problem" http://blogs.msdn.com/mahjayar/archive/2006/10/14/debugging-whidbey-remoting -accessviolation-problem.aspx Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
I do not use any pinvoke but the ones to read ini files. However those calls
are done once at the start of the program and nomore, and the crash occours after hours of working, so I don't think that is due to pinvoke Anyway, you can download the dump at http://88.50.196.11/pub/dump.dump Thanks Cristian Mori [quoted text, click to view] ""Jeffrey Tan[MSFT]"" wrote:
> Hi Cristian, > > Can you save a dump of this exception and then provide a way for me to > download? You may use .dump command to get this done in windbg. > > Most of time managed heap corruptions were coming from some bad PInvokes to > some native APIs. > > You may get a look at: > ".NET Crash: Managed Heap Corruption calling unmanaged code" > http://blogs.msdn.com/tess/archive/2006/02/09/528591.aspx > and > "Debugging Whidbey Remoting AccessViolation Problem" > http://blogs.msdn.com/mahjayar/archive/2006/10/14/debugging-whidbey-remoting > -accessviolation-problem.aspx > > Thanks. > > Best regards, > Jeffrey Tan > Microsoft Online Community Support > ================================================== > Get notification to my posts through email? Please refer to > http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif > ications. > > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues > where an initial response from the community or a Microsoft Support > Engineer within 1 business day is acceptable. Please note that each follow > up response may take approximately 2 business days as the support > professional working with you may need further investigation to reach the > most efficient resolution. The offering is not appropriate for situations > that require urgent, real-time or phone-based interactions or complex > project analysis and dump analysis issues. Issues of this nature are best > handled working with a dedicated Microsoft Support Engineer by contacting > Microsoft Customer Support Services (CSS) at > http://msdn.microsoft.com/subscriptions/support/default.aspx. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. > >
Hi Cristian,
I have found a lot of similar errors and stack traces in our internal database. It looks like some type of corruption in the managed heap of CLR, which is somewhat tough to debug. I would recommend you to use the following command to verify the managed heap: load sos !VerifyHeap Please paste the heap verification output here. Thanks. If you failed to find sos.dll, please feel free to article below to understand how to load sos.dll: "Bugslayer: SOS: It's Not Just an ABBA Song Anymore" http://msdn.microsoft.com/msdnmag/issues/03/06/Bugslayer/ Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
[quoted text, click to view] "MoriCristian" <CristianMori@nospam.nospam> wrote in message news:B7DF215B-3D51-42F4-B2FC-EB5329E571FC@microsoft.com... >I do not use any pinvoke but the ones to read ini files. However those >calls > are done once at the start of the program and nomore, and the crash > occours > after hours of working, so I don't think that is due to pinvoke Can you try setting a breakpoint and running VerifyHeap after you finish the ini file load? [quoted text, click to view] > > Anyway, you can download the dump at > http://88.50.196.11/pub/dump.dump > > Thanks > Cristian Mori > > ""Jeffrey Tan[MSFT]"" wrote: > >> Hi Cristian, >> >> Can you save a dump of this exception and then provide a way for me to >> download? You may use .dump command to get this done in windbg. >> >> Most of time managed heap corruptions were coming from some bad PInvokes >> to >> some native APIs. >> >> You may get a look at: >> ".NET Crash: Managed Heap Corruption calling unmanaged code" >> http://blogs.msdn.com/tess/archive/2006/02/09/528591.aspx >> and >> "Debugging Whidbey Remoting AccessViolation Problem" >> http://blogs.msdn.com/mahjayar/archive/2006/10/14/debugging-whidbey-remoting >> -accessviolation-problem.aspx >> >> Thanks. >> >> Best regards, >> Jeffrey Tan >> Microsoft Online Community Support >> ================================================== >> Get notification to my posts through email? Please refer to >> http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif >> ications. >> >> Note: The MSDN Managed Newsgroup support offering is for non-urgent >> issues >> where an initial response from the community or a Microsoft Support >> Engineer within 1 business day is acceptable. Please note that each >> follow >> up response may take approximately 2 business days as the support >> professional working with you may need further investigation to reach the >> most efficient resolution. The offering is not appropriate for situations >> that require urgent, real-time or phone-based interactions or complex >> project analysis and dump analysis issues. Issues of this nature are best >> handled working with a dedicated Microsoft Support Engineer by contacting >> Microsoft Customer Support Services (CSS) at >> http://msdn.microsoft.com/subscriptions/support/default.aspx. >> ================================================== >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> >> >>
Hi jeffrey
You can find the full dump (138 MB!) in http://88.50.196.11/pub/fulldump.dump the only native calls are those two [DllImport("kernel32")] private static extern long WritePrivateProfileString(string section, string key,string val,string filePath); [DllImport("kernel32")] private static extern int GetPrivateProfileString(string section, string key,string def, StringBuilder retVal, int size,string filePath); but even removing them the program crashes in the same way Waiting for your replay Regards Cristian Mori [quoted text, click to view] ""Jeffrey Tan[MSFT]"" wrote:
> Hi Cristian, > > Oh, sorry, my fault, I should tell you to use ".dump /f" to create a full > dump instead of minidump. Can I bother you to create a full dump for this > issue? We unfortunately cannot get useful information from that mini dump. > > In the meantime you might want to look for any places where you call native > APIs passing buffers where the api would write beyond the bounds of the > buffer. In your scenario, you might be want to check the APIs for reading > ini files. Note: memory corruption may not arise immediately, it may result > in AV long time later, so it is hard to troubleshoot. > > Thanks. > > Best regards, > Jeffrey Tan > Microsoft Online Community Support > ================================================== > Get notification to my posts through email? Please refer to > http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif > ications. > > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues > where an initial response from the community or a Microsoft Support > Engineer within 1 business day is acceptable. Please note that each follow > up response may take approximately 2 business days as the support > professional working with you may need further investigation to reach the > most efficient resolution. The offering is not appropriate for situations > that require urgent, real-time or phone-based interactions or complex > project analysis and dump analysis issues. Issues of this nature are best > handled working with a dedicated Microsoft Support Engineer by contacting > Microsoft Customer Support Services (CSS) at > http://msdn.microsoft.com/subscriptions/support/default.aspx. > ================================================== > This posting is provided "AS IS" with no warranties, and confers no rights. > >
Hi Cristian,
Oh, sorry, my fault, I should tell you to use ".dump /f" to create a full dump instead of minidump. Can I bother you to create a full dump for this issue? We unfortunately cannot get useful information from that mini dump. In the meantime you might want to look for any places where you call native APIs passing buffers where the api would write beyond the bounds of the buffer. In your scenario, you might be want to check the APIs for reading ini files. Note: memory corruption may not arise immediately, it may result in AV long time later, so it is hard to troubleshoot. Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Hi Cristian,
This problem is a bit complex to paste in the newsgroup. I have sent an email to you for this problem. Thanks. Best regards, Jeffrey Tan Microsoft Online Community Support ================================================== Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications. Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx. ================================================== This posting is provided "AS IS" with no warranties, and confers no rights.
Hi!, any news?
Regards Cristian Mori [quoted text, click to view] "MoriCristian" wrote:
> Hi jeffrey > You can find the full dump (138 MB!) in > http://88.50.196.11/pub/fulldump.dump > > the only native calls are those two > > [DllImport("kernel32")] > private static extern long WritePrivateProfileString(string section, > string key,string val,string filePath); > [DllImport("kernel32")] > private static extern int GetPrivateProfileString(string section, > string key,string def, StringBuilder retVal, > int size,string filePath); > > but even removing them the program crashes in the same way > > Waiting for your replay > Regards > Cristian Mori > > ""Jeffrey Tan[MSFT]"" wrote: > > > Hi Cristian, > > > > Oh, sorry, my fault, I should tell you to use ".dump /f" to create a full > > dump instead of minidump. Can I bother you to create a full dump for this > > issue? We unfortunately cannot get useful information from that mini dump. > > > > In the meantime you might want to look for any places where you call native > > APIs passing buffers where the api would write beyond the bounds of the > > buffer. In your scenario, you might be want to check the APIs for reading > > ini files. Note: memory corruption may not arise immediately, it may result > > in AV long time later, so it is hard to troubleshoot. > > > > Thanks. > > > > Best regards, > > Jeffrey Tan > > Microsoft Online Community Support > > ================================================== > > Get notification to my posts through email? Please refer to > > http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif > > ications. > > > > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues > > where an initial response from the community or a Microsoft Support > > Engineer within 1 business day is acceptable. Please note that each follow > > up response may take approximately 2 business days as the support > > professional working with you may need further investigation to reach the > > most efficient resolution. The offering is not appropriate for situations > > that require urgent, real-time or phone-based interactions or complex > > project analysis and dump analysis issues. Issues of this nature are best > > handled working with a dedicated Microsoft Support Engineer by contacting > > Microsoft Customer Support Services (CSS) at > > http://msdn.microsoft.com/subscriptions/support/default.aspx. > > ================================================== > > This posting is provided "AS IS" with no warranties, and confers no rights. > > > >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |