ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.
One of a set of tools we're offering as a way to say thank you for being a part of the community.
.NET application crash rarely
Dear Experts,
An application written in .NET Framework 2.0 was running without any issue for more than 2 yrs. Sometime back the application (deployed as a windows service) has stopped itself. The attached error has been logged in eventvwr (Please refer Server Crash image). How to identify the root cause of the issue and how to resolve it. Kindly assist.
NOTE:
After the server application crashed, the respective client application as well shuts down (Please refer Client Crash image)
At the time of server crash the memory page utilization is more. After the restart of the service it is normal now. Thought to take the memory dumps. But the application works fine now it won't be helpful I think. Please let me know if you have any other suggestion to nail down the issue. Thanks in advance.
ClientCrash.jpg
ServerCrash.jpg
An application written in .NET Framework 2.0 was running without any issue for more than 2 yrs. Sometime back the application (deployed as a windows service) has stopped itself. The attached error has been logged in eventvwr (Please refer Server Crash image). How to identify the root cause of the issue and how to resolve it. Kindly assist.
NOTE:
After the server application crashed, the respective client application as well shuts down (Please refer Client Crash image)
At the time of server crash the memory page utilization is more. After the restart of the service it is normal now. Thought to take the memory dumps. But the application works fine now it won't be helpful I think. Please let me know if you have any other suggestion to nail down the issue. Thanks in advance.
ClientCrash.jpg
ServerCrash.jpg
Asked:
2-
2
2 Solutions
It is possible that this *might* address your problem.
http://support.microsoft.com/kb/2276255/en-us
According to Microsoft:
http://support.microsoft.com/kb/2276255/en-us
According to Microsoft:
This problem occurs because the maximum number of processors that the common language runtime (CLR) 2.0 can report is 32. However, when the NtGetCurrentProcessorNumbe-saige-r function obtains the actual number of processors in the computer, and this number is greater than 32 processors, the ThreadpoolMgr::RecycleMemo ry method enters an infinite loop.
@Kimputer: The current version of the .net version is 2.0.50727.1873. Please let me know how to make sure that the minimum version .8009 is required? Is this anywhere documented? Please share the details. Thanks is advance!
.8009 is for newer systems (like Win8), while WinXP is stuck at .3658
The only way it's not updated is if you disabled Windows Update (which is not safe!)
With Windows Update enabled, every now and then .Net will get updates (in your case, probably 50 .Net updates waiting)
The only way it's not updated is if you disabled Windows Update (which is not safe!)
With Windows Update enabled, every now and then .Net will get updates (in your case, probably 50 .Net updates waiting)
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
Featured Post
Tackle projects and never again get stuck behind a technical roadblock.
Join Now
But since I can tell from the version number you're a bit behind, how about fully updating your .Net ? I think the last numbers should jump at least to .8009 (maybe less on WinXP, but still it seems you're a bit behind).
Hopefully this bug had already been squashed somewhere between those updates.