select s.username, s.osuser, s.sid, s.serial#, p.spid
from v$session s,v$process p
where s.paddr = p.addr
and s.username is not null;
This will return the database username, the operating system username, the session id, the serial number, and the system process id (SPID). Then, a DBA user can issue the following (using the SID and SERIAL# information from the previous query):
ALTER SYSTEM KILL SESSION 'sid,serial#';
ALTER SYSTEM KILL SESSION '9,203';
Saturday, June 02, 2007
Wednesday, February 14, 2007
disabling browser back button
Its a very common question that many of the developers need often.
I am too interested how we can do this.
Oftent he problem is that after logout, if user clicks back in the browser and is able to see content, this is not expected. there will be many advantages if we can disable back button especially when we require it.
Cache control:
one of the best and easiest way to handle issues popup because of clicking back button is to set no cache for the pages.
setting no cache:
You can use client-side code to force the user's browser to not cache a Web page.
<html>
<head>
<meta http-equiv="Expires" CONTENT="0">
<meta http-equiv="Cache-Control" CONTENT="no-cache">
<meta http-equiv="Pragma" CONTENT="no-cache">
</head>
There are a couple things to keep in mind when using the above method to force a browser to not
cache a Web page:
[Try out the above link!]
I am too interested how we can do this.
Oftent he problem is that after logout, if user clicks back in the browser and is able to see content, this is not expected. there will be many advantages if we can disable back button especially when we require it.
Cache control:
one of the best and easiest way to handle issues popup because of clicking back button is to set no cache for the pages.
setting no cache:
You can use client-side code to force the user's browser to not cache a Web page.
<html>
<head>
<meta http-equiv="Expires" CONTENT="0">
<meta http-equiv="Cache-Control" CONTENT="no-cache">
<meta http-equiv="Pragma" CONTENT="no-cache">
</head>
There are a couple things to keep in mind when using the above method to force a browser to not
cache a Web page:
Pragma: no-cacheprevents caching only when used over a secure connection.
APragma: no-cacheMETA tag is treated identically toExpires: -1if used in a
non-secure page. The page will be cached but marked as immediately expired.Cache-ControlMETAHTTP-EQUIVtags are ignored and have no effect in Internet
Explorer versions 4 or 5.
You can use both in your code. I tried this but this was not the solution because it did not work in all the
browsers so I guess if one had an intranet environment where there was some control in place then they could
use this method.
Javascript
My next area of research focused on the various rewiring the back button suggestions. An article by TJ
Sylvester, Rewiring the Back Button, makes interesting reading but I
noticed that when one clicks back it does not indeed take you to the page you entered the data but if I
clicked back twice it does and we would not want that too. Basically a determined user could always figure
out a way to circumvent the preventative measures.
Another way to "disable the back button" is to use client-side JavaScript code to open a new window that
doesn't have the toolbar. (This makes it harder (not impossible) for the user to go back to the previous
page.)
Another, more failsafe approach (although quite annoying) is, when a form is submitted, to open a new window
and close the window that the form existed in. I didn't give this method serious thought because
I would not like my site opening up a new window everytime a user submitted a form.
Next I examined the possibility of adding client-side JavaScript code on the page that we do not want to let
the user return to. Such JavaScript code could be used to have the effect of hitting the forward button, which would
counter any action by a user clicking the back button. The JavaScript code to accomplish this can be seen below:
|
Again this is workable but it is far from the best way.
I was then given the suggestion to use location.replace to navigate form one page to another.
What this does is it replaces the current history entry with the new page so only one page will be maintained
in the history and the back button will never get enabled. This is, I guess, what a lot of people are looking
for, but again this would not be the best answer in all cases.
For one thing you will have to use client side script for this. For an anchor tag this will be easy by just
using:
|
The above technique has its disadvantages: simply using Response.Redirect will not work, since,
each time a user jumps from one page to another, you need to clear out the location.history field
through client-side code. Also, keep in mind that this will just remove the last history entry, not all
of them. Go ahead and click the above hyperlink, you will be taken to a simple HTML page. Try clicking the back button
and you will notice you will be taken to the page you were visiting before you came to this page! (Assuming,
of course, you have client-side JavaScript code enabled in your browser.)
After my exhaustive search I found that there is still no way of truly disabling the back button for all cases.
All the methods I discussed in this article will, with varying degrees of success, prevent the
user from viewing the previous page, but they, of course, all have their limitations. The best solution involves
a mixture of both client-side and server-side script; regardless, there is no way to completely disable the back
button
JSP
%
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
%>
ASP.NET
Response.CacheControl = "no-cache";
Proxy Server Caching-
Response.CacheControl = "private";
It disables the proxy server caching and page is cached on local machine.
Response.CacheControl = "public";
Proxy server cache is enabled.
Users request pages from a local server instead of direct from the source.
Friday, February 02, 2007
Thursday, February 01, 2007
Setting default browser
To make Internet Explorer the default web browser,
In Internet Explorer -> View menu -> Internet Options -> Programs
Enable
'Internet Explorer should check to see whether it is the default web browser'
To make firefox as your default browser
Go to Tools -> Options.
under general tab, check the check box for "Firefox should check to see if it is the default browser when starting".
or you have a button "check now" if you click that you will get an alert if firefox is not the default browser. if you click yes, then it will become default browser.
In Internet Explorer -> View menu -> Internet Options -> Programs
Enable
'Internet Explorer should check to see whether it is the default web browser'
To make firefox as your default browser
Go to Tools -> Options.
under general tab, check the check box for "Firefox should check to see if it is the default browser when starting".
or you have a button "check now" if you click that you will get an alert if firefox is not the default browser. if you click yes, then it will become default browser.
Thursday, January 18, 2007
Browser detection
Using the navigator object to detect client's browser
Until one browser remains standing on the web (if ever), browser detection will continue to be part of any good JavaScripter's life. Whether you're gliding a div across the screen or creating an image rollover, it's fundamental that only relevant browsers pick up on your code. In this tutorial we'll probe the navigator object of JavaScript, and show how to use it to perform browser detection, whether the subject is Firefox, Internet Explorer 6, or even Opera 8.
The navigator object
The navigator object was conceived back in the days when Netscape Navigatorreined supreme. These days it serves as much as an irony of NS's diminished market share as way of probing browser information.
The navigator object of JavaScript contains the following core properties:
Properties
Description
appCodeName
The code name of the browser.
appName
The name of the browser (ie: Microsoft Internet Explorer).
appVersion
Version information for the browser (ie: 4.75 [en] (Win98; U)).
cookieEnabled
Boolean that indicates whether the browser has cookies enabled. IE4 and NS6+.
language
Returns the default language of the browser version (ie: en-US). NS4 and NS6+ only.
mimeTypes[]
An array of all MIME types supported by the client. NS4 and NS6+ only. Array is always empty in IE.
platform[]
The platform of the client's computer (ie: Win32).
plugins
An array of all plug-ins currently installed on the client. NS4 and NS6+ only. Array is always empty in IE.
systemLanguage
IE4+ property that returns the default language of the operating system. Similar to NS's language property.
userAgent
String passed by browser as user-agent header. (ie: Mozilla /4.0 (compatible; MSIE 6.0; Windows NT 5.1))
userLanguage
IE4+ property that returns the preferred language setting of the user. Similar to NS's language property.
Let's see exactly what these properties reveal of your browser:
with (document){
write("AppCodeName: "+navigator.appCodeName+"")
write("AppName: "+navigator.appName+"")
write("AppVersion: "+navigator.appVersion+"")
write("UserAgent: "+navigator.userAgent+"")
write("Platform: "+navigator.platform+"")
}
AppCodeName: MozillaAppName: Microsoft Internet ExplorerAppVersion: 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)Platform: Win32
At a glance
You probably think you have a very solid idea now of how to utilize the navigator object to detect your client's browser type. At its most basic form, the following two properties are used:
navigator.appNamenavigator.appVersion
For example:
//detect Netscape 4.7+
if (navigator.appName=="Netscape"&&parseFloat(navigator.appVersion)>=4.7)
alert("You are using Netscape 4.7+")
However, depending on the browser you're trying to detect, you'll find the above two properties too limiting.
Detecting Firefox 1.0+
Take for example, Firefox 1.0+. It shares the same "appName" value as older Netscape browsers, which is "Netscape." The appVersion value returned is also out of wack, which is "5." So we need to look to another property, which turns out to be "UserAgent." For Firefox 1.04 for example, its userAgent property reads:
UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Ah ha, the text at the end of the string apparently contains the information we want. Based on this new found discovery, the below code detects if you're using Firefox 1.0+:
if(navigator.userAgent.indexOf("Firefox")!=-1){
var versionindex=navigator.userAgent.indexOf("Firefox")+8
if (parseInt(navigator.userAgent.charAt(versionindex))>=1)
alert("You are using Firefox 1.x or above")
}
The code assumes that all Firefox versions contain the string "Firefox/" immediately followed by the version number (ie "1").
Detecting IE 5.5+
Detecting IE using the navigator object also poses a similar problem as Firefox, since its "navigator.appVersion" property contains more than just the version number of IE:
4.0 (compatible; MSIE 5.5; Windows 98; Hotbar 3.0)
If we were to use parseFloat to try and extract out the browser version in "navigator.appVersion", we'd get 4.0, instead of the correct number (5.5). This is due to the way parseFloat works- by returning the first number it encounters. So, how does one go about getting the version number in IE? As with Firefox, it really comes down to how you wish to approach the issue. Lets stick with using the "navigator.appVersion" property this time, though you can certainly use "navigator.userAgent" as well:
//Detect IE5.5+
version=0
if (navigator.appVersion.indexOf("MSIE")!=-1){
temp=navigator.appVersion.split("MSIE")
version=parseFloat(temp[1])
}
if (version>=5.5) //NON IE browser will return 0
alert("You're using IE5.5+")
In the above, string.split() is first used to divvy up navigator.appVersion into two parts, using "MSIE" as the separator:
4.0 (compatible; MSIE 5.5; Windows 98; Hotbar 3.0)
As a result temp[1] contains the part after "MSIE", with the browser version appearing first. Doing a parseFloat() on temp[1] therefore retrieves the browser version of IE.
The Opera pitfall
Using the navigator object to screen for Opera is even a little more complex, as Opera by default identifies itself as IE, with Opera 8 identifying itself as IE6, inside "navigator.userAgent." The rationale for this is so that scripts screening for IE would also allow Opera through, so that Opera will render these pages properly. Lets take a look at what the userAgent of Opera 8.5 returns depending on what it is set to identify as:
As IE6: Mozilla/4.0 (compatible; MSIE 6.0; Windows XP) Opera 8.5 [en]As Moz5: Mozilla/5.0 (Windows XP; U) Opera 8.5 [en]As Opera: Opera/8.5 (Windows XP; U) [en]
"What's the problem? Opera 8.5 appears in each case." you may say. Well, look closer, and notice how when Opera is set to identify as itself, the Opera string returned is slightly different ("Opera/8.5" versus "Opera 8.5"). So ironically enough, the expressionif (navigator.userAgent.indexOf("Opera 8.5")!=-1)
will fail if the user has their browser set to identify as Opera, but not if any other browser!
Despite this oddity, the code to detecting Opera need not be any different than the one used to detect Firefox:
if(navigator.userAgent.indexOf("Opera")!=-1){
var versionindex=navigator.userAgent.indexOf("Opera")+6
if (parseInt(navigator.userAgent.charAt(versionindex))>=8)
alert("You are using Opera 8 or 9")
}
This also assumes that all Opera versions contain the string "Opera" immediately followed by either a space or "/", then the version number (ie "8"). And since it only looks at the first number within the version, it can only detect up to Opera 9, not 10 for example.
Using object detection to sniff out different browsers
Since different browsers support different objects, you can use Object Detection as a quick though less than infallible way of detecting various browsers. For example, since only Opera supports the property "window.opera", you can use that to instantly separate an Opera browser from the herd. Here are a few sample test cases, and what they *imply* about the browser running it:
Example objects used to "rough" detect a particular browser
Scheme
Description
document.getElementById
Detects modern browsers in general, which covers IE5+, Firefox1+, and Opera7+
window.getComputedStyle
Detects Firefox1+ and Opera 8+
Array.every
Detects Firefox1.5+ (method detection)
window.Iterator
Detects Firefox2+
document.all
Detects IE4+
window.attachEvent
Detects IE5+
window.createPopup
Detects IE5.5+
document.compatMode && document.all
Detects IE6+
window.XMLHttpRequest
Detects IE7, Firefox1+, and Opera8+
window.XMLHttpRequest && document.all
Detects IE7. Note: Will fail if visitor explicitly disables native xmlHTTPRequest support (under Toolbar-> Internet Options-> Advanced)
document.documentElement && typeof document.documentElement.style.maxHeight!="undefined"
Another way of detecting IE7 that is more reliable than the above.
window.opera
Detects Opera (any version).
* Since Opera by default also identifies itself as IE (apart from Opera), with support for many of IE's proprietary objects, the IE detection schemes above will also return true for Opera. Use "window.opera" in combination to filter out Opera browsers.
It's important to mention that object detection's chief purpose is to help you detect within your script whether the browser supports a particular object/method/property before using it, not browser detection. As the later it may be convenient over probing the Navigator object, but is only as reliable as your understanding of which objects are supported in which browsers. In other words, it's not a 100% reliable way of sniffing out the user's browser. Having said that, the below uses object detection to test for IE7:
Again object detection is really about feature detection. It detects whether your browser supports the feature your script intends to use and manipulate. For the lazy, that will substitute for browser detection just fine!
Until one browser remains standing on the web (if ever), browser detection will continue to be part of any good JavaScripter's life. Whether you're gliding a div across the screen or creating an image rollover, it's fundamental that only relevant browsers pick up on your code. In this tutorial we'll probe the navigator object of JavaScript, and show how to use it to perform browser detection, whether the subject is Firefox, Internet Explorer 6, or even Opera 8.
The navigator object
The navigator object was conceived back in the days when Netscape Navigatorreined supreme. These days it serves as much as an irony of NS's diminished market share as way of probing browser information.
The navigator object of JavaScript contains the following core properties:
Properties
Description
appCodeName
The code name of the browser.
appName
The name of the browser (ie: Microsoft Internet Explorer).
appVersion
Version information for the browser (ie: 4.75 [en] (Win98; U)).
cookieEnabled
Boolean that indicates whether the browser has cookies enabled. IE4 and NS6+.
language
Returns the default language of the browser version (ie: en-US). NS4 and NS6+ only.
mimeTypes[]
An array of all MIME types supported by the client. NS4 and NS6+ only. Array is always empty in IE.
platform[]
The platform of the client's computer (ie: Win32).
plugins
An array of all plug-ins currently installed on the client. NS4 and NS6+ only. Array is always empty in IE.
systemLanguage
IE4+ property that returns the default language of the operating system. Similar to NS's language property.
userAgent
String passed by browser as user-agent header. (ie: Mozilla /4.0 (compatible; MSIE 6.0; Windows NT 5.1))
userLanguage
IE4+ property that returns the preferred language setting of the user. Similar to NS's language property.
Let's see exactly what these properties reveal of your browser:
with (document){
write("AppCodeName: "+navigator.appCodeName+"")
write("AppName: "+navigator.appName+"")
write("AppVersion: "+navigator.appVersion+"")
write("UserAgent: "+navigator.userAgent+"")
write("Platform: "+navigator.platform+"")
}
AppCodeName: MozillaAppName: Microsoft Internet ExplorerAppVersion: 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727)Platform: Win32
At a glance
You probably think you have a very solid idea now of how to utilize the navigator object to detect your client's browser type. At its most basic form, the following two properties are used:
navigator.appNamenavigator.appVersion
For example:
//detect Netscape 4.7+
if (navigator.appName=="Netscape"&&parseFloat(navigator.appVersion)>=4.7)
alert("You are using Netscape 4.7+")
However, depending on the browser you're trying to detect, you'll find the above two properties too limiting.
Detecting Firefox 1.0+
Take for example, Firefox 1.0+. It shares the same "appName" value as older Netscape browsers, which is "Netscape." The appVersion value returned is also out of wack, which is "5." So we need to look to another property, which turns out to be "UserAgent." For Firefox 1.04 for example, its userAgent property reads:
UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Ah ha, the text at the end of the string apparently contains the information we want. Based on this new found discovery, the below code detects if you're using Firefox 1.0+:
if(navigator.userAgent.indexOf("Firefox")!=-1){
var versionindex=navigator.userAgent.indexOf("Firefox")+8
if (parseInt(navigator.userAgent.charAt(versionindex))>=1)
alert("You are using Firefox 1.x or above")
}
The code assumes that all Firefox versions contain the string "Firefox/" immediately followed by the version number (ie "1").
Detecting IE 5.5+
Detecting IE using the navigator object also poses a similar problem as Firefox, since its "navigator.appVersion" property contains more than just the version number of IE:
4.0 (compatible; MSIE 5.5; Windows 98; Hotbar 3.0)
If we were to use parseFloat to try and extract out the browser version in "navigator.appVersion", we'd get 4.0, instead of the correct number (5.5). This is due to the way parseFloat works- by returning the first number it encounters. So, how does one go about getting the version number in IE? As with Firefox, it really comes down to how you wish to approach the issue. Lets stick with using the "navigator.appVersion" property this time, though you can certainly use "navigator.userAgent" as well:
//Detect IE5.5+
version=0
if (navigator.appVersion.indexOf("MSIE")!=-1){
temp=navigator.appVersion.split("MSIE")
version=parseFloat(temp[1])
}
if (version>=5.5) //NON IE browser will return 0
alert("You're using IE5.5+")
In the above, string.split() is first used to divvy up navigator.appVersion into two parts, using "MSIE" as the separator:
4.0 (compatible; MSIE 5.5; Windows 98; Hotbar 3.0)
As a result temp[1] contains the part after "MSIE", with the browser version appearing first. Doing a parseFloat() on temp[1] therefore retrieves the browser version of IE.
The Opera pitfall
Using the navigator object to screen for Opera is even a little more complex, as Opera by default identifies itself as IE, with Opera 8 identifying itself as IE6, inside "navigator.userAgent." The rationale for this is so that scripts screening for IE would also allow Opera through, so that Opera will render these pages properly. Lets take a look at what the userAgent of Opera 8.5 returns depending on what it is set to identify as:
As IE6: Mozilla/4.0 (compatible; MSIE 6.0; Windows XP) Opera 8.5 [en]As Moz5: Mozilla/5.0 (Windows XP; U) Opera 8.5 [en]As Opera: Opera/8.5 (Windows XP; U) [en]
"What's the problem? Opera 8.5 appears in each case." you may say. Well, look closer, and notice how when Opera is set to identify as itself, the Opera string returned is slightly different ("Opera/8.5" versus "Opera 8.5"). So ironically enough, the expressionif (navigator.userAgent.indexOf("Opera 8.5")!=-1)
will fail if the user has their browser set to identify as Opera, but not if any other browser!
Despite this oddity, the code to detecting Opera need not be any different than the one used to detect Firefox:
if(navigator.userAgent.indexOf("Opera")!=-1){
var versionindex=navigator.userAgent.indexOf("Opera")+6
if (parseInt(navigator.userAgent.charAt(versionindex))>=8)
alert("You are using Opera 8 or 9")
}
This also assumes that all Opera versions contain the string "Opera" immediately followed by either a space or "/", then the version number (ie "8"). And since it only looks at the first number within the version, it can only detect up to Opera 9, not 10 for example.
Using object detection to sniff out different browsers
Since different browsers support different objects, you can use Object Detection as a quick though less than infallible way of detecting various browsers. For example, since only Opera supports the property "window.opera", you can use that to instantly separate an Opera browser from the herd. Here are a few sample test cases, and what they *imply* about the browser running it:
Example objects used to "rough" detect a particular browser
Scheme
Description
document.getElementById
Detects modern browsers in general, which covers IE5+, Firefox1+, and Opera7+
window.getComputedStyle
Detects Firefox1+ and Opera 8+
Array.every
Detects Firefox1.5+ (method detection)
window.Iterator
Detects Firefox2+
document.all
Detects IE4+
window.attachEvent
Detects IE5+
window.createPopup
Detects IE5.5+
document.compatMode && document.all
Detects IE6+
window.XMLHttpRequest
Detects IE7, Firefox1+, and Opera8+
window.XMLHttpRequest && document.all
Detects IE7. Note: Will fail if visitor explicitly disables native xmlHTTPRequest support (under Toolbar-> Internet Options-> Advanced)
document.documentElement && typeof document.documentElement.style.maxHeight!="undefined"
Another way of detecting IE7 that is more reliable than the above.
window.opera
Detects Opera (any version).
* Since Opera by default also identifies itself as IE (apart from Opera), with support for many of IE's proprietary objects, the IE detection schemes above will also return true for Opera. Use "window.opera" in combination to filter out Opera browsers.
It's important to mention that object detection's chief purpose is to help you detect within your script whether the browser supports a particular object/method/property before using it, not browser detection. As the later it may be convenient over probing the Navigator object, but is only as reliable as your understanding of which objects are supported in which browsers. In other words, it's not a 100% reliable way of sniffing out the user's browser. Having said that, the below uses object detection to test for IE7:
Again object detection is really about feature detection. It detects whether your browser supports the feature your script intends to use and manipulate. For the lazy, that will substitute for browser detection just fine!
Task Manager menu /tabs disappear
last one or 2 days when ever i open task manager to kill some process, it just shows up without any menu bar/ tabs
i thought it could be a virus effect or something, but when i searched on net it gave a solution.
SYMPTOMS
loadTOCNode(1, 'symptoms');
When you start Task Manager, the menu bar and tabs may not be visible.
Back to the top
CAUSE
loadTOCNode(1, 'cause');
This behavior can occur if Task Manager is running in Tiny Footprint mode. When you double-click the empty space in the border around the tabs, Task Manager switches to this mode.
Back to the top
RESOLUTION
loadTOCNode(1, 'resolution');
To switch Task Manager to its normal display mode, double-click the top border of the window.
Back to the top
WORKAROUND
loadTOCNode(1, 'workaround');
To work around this behavior, perform the following steps:
1.
Click Start, and then click Run.
2.
Type taskmgr.exe.
3.
Hold down CTRL+ALT+SHIFT at the same time, and while holding them down press ENTER.
Reference :http://support.microsoft.com/kb/193050
i thought it could be a virus effect or something, but when i searched on net it gave a solution.
SYMPTOMS
loadTOCNode(1, 'symptoms');
When you start Task Manager, the menu bar and tabs may not be visible.
Back to the top
CAUSE
loadTOCNode(1, 'cause');
This behavior can occur if Task Manager is running in Tiny Footprint mode. When you double-click the empty space in the border around the tabs, Task Manager switches to this mode.
Back to the top
RESOLUTION
loadTOCNode(1, 'resolution');
To switch Task Manager to its normal display mode, double-click the top border of the window.
Back to the top
WORKAROUND
loadTOCNode(1, 'workaround');
To work around this behavior, perform the following steps:
1.
Click Start, and then click Run.
2.
Type taskmgr.exe.
3.
Hold down CTRL+ALT+SHIFT at the same time, and while holding them down press ENTER.
Reference :http://support.microsoft.com/kb/193050
Service unavailable
Hi guys,
Service unavailable error in IIS 6 (Windows 2003 server) is really a painful one.
It is occurring because the application pool supporting your asp.net application has just crashed.
One way to get away from this error is to increase the error condition.
Set the health condtions as shown in the image. increase threshold of error count.
I am not sure if this is the right solution, but this worked for me.
Thursday, January 11, 2007
System internals
http://www.microsoft.com/technet/sysinternals/default.mspx
The Sysinternals web site was created in 1996 by Mark Russinovich and Bryce Cogswell to host their advanced system utilities and technical information. Microsoft acquired Sysinternals in July, 2006.
The Sysinternals web site was created in 1996 by Mark Russinovich and Bryce Cogswell to host their advanced system utilities and technical information. Microsoft acquired Sysinternals in July, 2006.
client application - intermittently receiving an error
A client application may intermittently receive an error message when a client application tries to create a COM+ component
View products that this article applies to.
Article ID : 911359
Last Review : January 20, 2006
Revision : 2.0
SYMPTOMS
When a client application tries to create a Microsoft COM+ component, the client application may intermittently receive an error message. Microsoft C++ applications may receive the following error message:
E_INVALIDARG: "The parameter is incorrect" (0x80070057/-2147024809)
Microsoft Visual Basic 6.0 applications may receive the following error message:
Run-time error '5': "Invalid procedure call or argument" (0x800a0005/-2146828283)
Client applications that are built on the Microsoft .NET Framework may receive the following error message:
System.ArgumentException: "The parameter is incorrect." at System.Runtime.Type.CreateInstanceImpl(Boolean publicOnly) at System.Activator.CreateInstance(Type type, Boolean nonPublic) (with _HResult = 0x80070057/-2147024809)
The COM+ application will typically function without error for some time immediately after the COM+ application is opened. The problem occurs intermittently, but increases in frequency over time until the application eventually fails on every activation request.
Note When the client application is running on a remote computer, the following error message is logged in the system event log on the client computer:
Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10006
Description:
DCOM got error "One or more arguments are invalid " from the computer SERVERNAME when attempting to activate the server: GUID
Back to the top
CAUSE
This problem occurs because the "COM initialization count" for a thread is incremented and decremented when the CoInitialize function and the CoUninitialize function are called. When this count reaches zero after you call the CoUninitialize function, COM will be uninitialized on the thread. When a COM+ STA ThreadPool thread is uninitialized, the thread's apartment activator is destroyed. The next activation request that is routed to this thread will fail with the E_INVALIDARG error message. This problem occurs because the thread apartment activator is no longer available. Only activation requests that are routed to the particular uninitialized thread will fail. As more COM+ ThreadPool threads become uninitialized, a larger percentage of requests will fail. When all COM+ ThreadPool threads become uninitialized, all requests will fail. If the process is restarted, the problem will recover for some time. However, the cycle will be repeated.
Back to the top
RESOLUTION
To resolve this problem, remove the CoInitialize calls and the CoUninitialize calls from the affected COM DLL. A COM DLL that exposes COM components and is loaded through COM calls from a client should not call the CoInitialize function or the CoUninitialize function on any thread that is used to load or to start the DLL. These threads are owned by the client application, by the COM runtime, or by the COM+ runtime. Only the COM DLL should call these APIs on additional threads that were explicitly created by the COM DLL. However, it is a common bug for COM DLLs to call the CoInitialize function and the CoUninitialize function in response to attach events and detach events in the DllMain function.
Note It is correct for a standard Win32 DLL that is not loaded through COM to call these APIs if the standard Win32 DLL plans to use COM APIs. However, these functions should not be called from the DllMain function.
For more information about the CoInitialize function, visit the following Microsoft Developer Network (MSDN) Web site:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/0f171cf4-87b9-43a6-97f2-80ed344fe376.asp (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/0f171cf4-87b9-43a6-97f2-80ed344fe376.asp)
For more information about the DllMain function, visit the following MSDN Web site:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp)
Note One Microsoft component that contains this bug is the Cdo.dll component. This component is not supported in multithreaded environments. Instead, we recommend that you use the Cdosys.dll component or the Cdonts.dll component. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
247288 (http://support.microsoft.com/kb/247288/) CDO applications are not supported in MTS or COM+
View products that this article applies to.
Article ID : 911359
Last Review : January 20, 2006
Revision : 2.0
SYMPTOMS
When a client application tries to create a Microsoft COM+ component, the client application may intermittently receive an error message. Microsoft C++ applications may receive the following error message:
E_INVALIDARG: "The parameter is incorrect" (0x80070057/-2147024809)
Microsoft Visual Basic 6.0 applications may receive the following error message:
Run-time error '5': "Invalid procedure call or argument" (0x800a0005/-2146828283)
Client applications that are built on the Microsoft .NET Framework may receive the following error message:
System.ArgumentException: "The parameter is incorrect." at System.Runtime.Type.CreateInstanceImpl(Boolean publicOnly) at System.Activator.CreateInstance(Type type, Boolean nonPublic) (with _HResult = 0x80070057/-2147024809)
The COM+ application will typically function without error for some time immediately after the COM+ application is opened. The problem occurs intermittently, but increases in frequency over time until the application eventually fails on every activation request.
Note When the client application is running on a remote computer, the following error message is logged in the system event log on the client computer:
Event Type: Error
Event Source: DCOM
Event Category: None
Event ID: 10006
Description:
DCOM got error "One or more arguments are invalid " from the computer SERVERNAME when attempting to activate the server: GUID
Back to the top
CAUSE
This problem occurs because the "COM initialization count" for a thread is incremented and decremented when the CoInitialize function and the CoUninitialize function are called. When this count reaches zero after you call the CoUninitialize function, COM will be uninitialized on the thread. When a COM+ STA ThreadPool thread is uninitialized, the thread's apartment activator is destroyed. The next activation request that is routed to this thread will fail with the E_INVALIDARG error message. This problem occurs because the thread apartment activator is no longer available. Only activation requests that are routed to the particular uninitialized thread will fail. As more COM+ ThreadPool threads become uninitialized, a larger percentage of requests will fail. When all COM+ ThreadPool threads become uninitialized, all requests will fail. If the process is restarted, the problem will recover for some time. However, the cycle will be repeated.
Back to the top
RESOLUTION
To resolve this problem, remove the CoInitialize calls and the CoUninitialize calls from the affected COM DLL. A COM DLL that exposes COM components and is loaded through COM calls from a client should not call the CoInitialize function or the CoUninitialize function on any thread that is used to load or to start the DLL. These threads are owned by the client application, by the COM runtime, or by the COM+ runtime. Only the COM DLL should call these APIs on additional threads that were explicitly created by the COM DLL. However, it is a common bug for COM DLLs to call the CoInitialize function and the CoUninitialize function in response to attach events and detach events in the DllMain function.
Note It is correct for a standard Win32 DLL that is not loaded through COM to call these APIs if the standard Win32 DLL plans to use COM APIs. However, these functions should not be called from the DllMain function.
For more information about the CoInitialize function, visit the following Microsoft Developer Network (MSDN) Web site:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/0f171cf4-87b9-43a6-97f2-80ed344fe376.asp (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/com/html/0f171cf4-87b9-43a6-97f2-80ed344fe376.asp)
For more information about the DllMain function, visit the following MSDN Web site:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp)
Note One Microsoft component that contains this bug is the Cdo.dll component. This component is not supported in multithreaded environments. Instead, we recommend that you use the Cdosys.dll component or the Cdonts.dll component. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
247288 (http://support.microsoft.com/kb/247288/) CDO applications are not supported in MTS or COM+
Service Unavailable - Application pool crash
HOWTO: Understand and Diagnose an Application Pool Crash
Problems statements similar to the following questions pop up all the time on various IIS newsgroups, and the user usually claims that they have either seen (or not seen) many posts that look like theirs, and never any concrete solutions. I am going to try and explain the whole thought process, why things work the way it does, as well as useful next steps.
Question:
#1
Our production server has recently started experiencing AppPool crashes. These seem to occur sporadically. sometimes three times a day, sometimes not for a couple of days. The error manifests itself to the client as "Service Unavailable". In the system event log we see the following:
A process serving application pool 'DefaultAppPool' suffered a fatal communication error with the World Wide Web Publishing Service With error number: 8007006d
At the same time (but not always) we see this error in the Application Log
"Faulting application w3wp.exe, version 6.0.3790.0, faulting module kernel32.dll, version 5.2.3790.0, fault address 0x000249d3"
The application does usually start working again after anywhere between 2 and 15 minutes (although no worker process restarts or recycles appear in our perf logs).
This problems seems to have started occuring following the latest MS patches being applied to our server. It may just be a coincidence though.
We are running Windows Server 2003 Standard. We are about to apply SP1 in an attempt to solve this problem, but I wanted to find out if anyone else has had this problem and what the solution was. I have seen several similarish posts but nothing concrete as a solution.
I have seen this article (http://support.microsoft.com/Default.aspx?id=885654) but it doesn't quite match our situation as we are not running as a domain controller. We haven't yet tried running registry monitor as I wanted to find out if error 8007006d always equates to a registry permission problem?? before installing
3rd party freeware onto our production server.
Any help is much appreciated
#2
There is a similar question posted today, but the event ID is different
I see the following error anywhere from 2-3 times a day on Windows 2003 server.
Event ID- 1009, a process serving application pool 'Q' terminated unexpectedly. The process ID was 'xxxx' . The process code was 'xxx'
So far we have not noticed anything on the application side, but once in a while W3WP.EXE starts using up all the CPU and the server comes to a halt. This is not associated with the application pool terminating, but wondering if it is conntributing it.
I have applied SP1 for Windows 2003, that did not make any difference.
Any help is apprciated.
#3
Hello Together!
I've got a problem with my Windows Server 2003 SP 1 Web-Edition
If I look in the event Viewer, I allways find the following Error:
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 28.08.2005
Time: 22:00:26
User: N/A
Computer: {removed by the author}
Description:
Faulting application w3wp.exe, version 6.0.3790.1830, faulting module, version , fault address 0x.
Why does this error occur? What is it and what can I do to resolve this problem?
Please help me
Answer:
You are looking at what is commonly refered to as a "crash" or "access violation" on the server. To be clear, this is different from a "hang" on the server, though the web browser may appear to "hang" or the browser's icon motions for some time (the length of time depends on various network connection timeout periods as well as whether the server-side connection stays open or closed) before reporting some random error response relating to missing server, DNS, or other service error.
Crash vs. Hang
What distinguishes between a crash and a hang on the server? Ok, for the astute reader in the back, just be quiet with this simplification. We want folks to to internalize and understand the issue, not regurgitate dry documentation. :-)
Practically speaking, a crash is something that will simply wipe out its host process; this will stop whatever server side work and response generation that the process was supposed to perform. Now, prior to IIS6, this same process also held the connection open, so as soon as a user-mode crash happens, IIS will go down and the client browsers see a disconnected connection and usually report some sort of service disconnected/not-found error. With IIS6 Worker Process Isolation Mode, HTTP.SYS holds the connections in kernel-mode, so regardless if user code running in w3wp.exe crashes, the connection stays connected and IIS starts up a new process to handle future requests - so browser clients will NOT see a disconnection for a crash. Unfortunately, the request caught by the crash cannot be re-executed (suppose that request was a bank withdraw...) unless you implemented Transaction semantics, so any unsent response is lost.
A hang, on the other hand, will usually keep its host process around but the hang prevents any real work from being done. There are many possible ways to do this - user code can be waiting for a lock that never gets released, either because it was leaked or there was a logical deadlock or livelock, or it could be in a clever infinite loop, etc. Once again, any unsent response will never happen once your code gets hung.
As you can see, from the perspective of the client browser, both a crash and a hang on the server can prevent a complete HTTP response from being sent back, so they can LOOK similar. Add to the fact that browsers may have bugs that cause itself to either crash and hang, and sound security practices on the server should limit information disclosure of errors to the client... so I never use browser behavior or returned HTML to diagnose server-side issues - I always diagnose based on information from various server log files.
About Diagnosing AppPool Failures...
Unfortunately, there are multiple event log entries from IIS that indicate a "crash" has happened, so you cannot just key-in on any particular event ID for a resolution pattern. For example, the earlier questions illustrate two such events, and there are other related ones.
Now, we did not intentionally try to make crashes harder to diagnose by making them appear as different events. What is happening is that the W3SVC component of IIS and the user-code execution component of IIS run in separate processes which execute independently of each other, yet asynchronously pass messages back and forth to indicate status. Suppose something crashes the process responsible for user-code execution...
Sometimes, IIS first notices it when a ping response fails to arrive; other times, IIS notices that the process handle has gone away... and while IIS understands that these are both catestrophic events that should be reported in the event log, it maintains good system design by reporting them uniquely. It is the responsibility of any analysis layers on top of IIS to abstract such detailed reporting and present a logical "process crashed" information to the user so that they can take action.
Unfortunately, that analysis layer is frequently the user's brain, who may not be able to abstract the details... and gets confused. But hey, I do not think that IIS should stop giving the details. On the contrary, I think you just have to look at the problem harder. :-) Or complain loudly and get us to provide a better debugging tool (like DebugDiag...).
What is a Crash
You can consider a crash as an unrecoverable event that resulted from some bug in the program that is executing - in the case of IIS, it simply provides a thin process and support infrastructure for your user code to run. And a bug is basically a logical flaw that results in unintended behavior given some arbitrary set of inputs. Notice that the behavior is unintended, and the set of causes is arbitrary. This basically means that bugs can cause crashes that happen sporadically or periodically... all depending on the set of causes, which is arbitrary!
Now, since the set of causes to a given bug is arbitrary, I would also caution against trying to "fix" crashes by blindly installing hotfixes, Service Packs, or making configuration changes. Crashes are caused by bugs, which are logical flaws, and the only way to "fix" the situation is to either:
fix the logical flaw itself, which requires diagnosing the crash to figure out the root of the problem.
change software configuration to avoid the logic flaw causing the crash, which can also require diagnosing the crash to figure out what is causing the issue.
To make things even more interesting... a variety of logic flaws can cause crashes, all of which look the same from an IIS and event log entry perspective (to IIS, the crash ended the process; does not matter what; so just report it).
Thus, you may see similar looking events, sometimes with similar looking error codes, but no single concrete solution. The reason should be clear to you now - one flaw causing a crash with a certain error code is NOT the same as another flaw causing a crash with an identical error code. You are talking about two different flaws, and depending on the code path taken by your server configuration choices, you may need to do different things.
So, the take-away here is that the event log entry, the error code, and any other details you may discern are simply good clues to what is going on, but none are independently reliable for diagnosis. Treat them as pieces of a puzzle that you need to put together to correctly diagnose the issue, which is ultimately what you are trying to identify and resolve.
For example, I treat these events as simply crashes that need to be caught and their stack trace logs analyzed to determine further action. I would not immediately pattern match crashes to "solutions" without other information, and I certainly would not change any system configuration in response.
Frankly, I think it is rash for users to attempt to resolve their crashes without diagnosing the cause. However, most users seem to love pattern matching problem symptoms and event log entries with supposed solutions and blindly try them all, hoping some might work... all the while sinking deeper into some other problem due to their random changes. And the rationale should be clear now - if you do not know the bug causing the fault, how can you determine the configuration change to avoid that bug's path, or find the right patch to fix the bug?
How to approach the Crash
Ok, now that I have thoroughly trashed most people's usual methods of "dealing" with a crash, let me walk through another troubleshooting pattern on IIS. :-) I realize that you are probably under the gun to take some action to fix a problem, so you are willing to try anything and if it works, great; if it doesn't, then there is always product support or newsgroup/forums support to fall back on. I just want to propose a more actionable way to deal with a crash, so that you may be able to take care of things yourself... doesn't that feel good? :-)
Since you never notice a server crash until you interact with it (usually with a browser), when something unexpected happened and you do not think it is a bug in the application ("hanging" browser or server-error responses are reasonable clues), it is time to look for any signs of a crash on the server. When IIS6 runs in its default Worker Process Isolation Mode, you will see event log entries similar to the sort given in the questions - either IIS noticed the w3wp.exe handle signaled process exit/crash of some sort, or the w3wp.exe fails to respond to a ping, or Windows notices that a process crashed. In IIS5 Compatibility Mode, you will probably notice other event log entries, either saying that the IISADMIN or W3SVC service crashed and has done this for # times, or that dllhost.exe has crashed, etc. Anyways, all these events talk about something related to IIS crashing; you have no idea whether it is due to your code or not.
Now that you have identified that your issue belongs to a crash, it is time to set up debugging traps so that you can catch the NEXT crash and diagnose it. Yes, you heard me - you cannot do anything about the crash that has already happened - and since you have no idea what it is, you CANNOT change any server settings to avoid it. So, the only reasonable thing you can do is to set up debugging monitors like IIS State or DebugDiag on the necessary processes running code that is crashing and then WAIT for the next crash. Hopefully, you can trigger the failure condition easily, to shorten this wait.
On this next crash, these tools will produce a stack trace log as well as memory dumps to allow debugging, and you want to either analyze the stack trace log yourself, pay someone to perform an analysis (for example, Microsoft PSS) or post to a newsgroup like microsoft.publit.inetserver.iis to see if anyone will do a free analysis. Only after analysis of the crash can you determine what is truly going wrong
Hopefully, you only have one crash happening on your server, but even if there are multiple crashes on your server, you simply apply the same technique in serial. You catch one crash, resolve it, get a patch/fix, and run again with debugging enabled to catch the next crash, get it resolved and a patch/fix, etc... As developers will say, crashes are the most straight forward to diagnose and fix - they are truly the low-hanging-fruit of bad behavior on the server, so you should pick them off real early...
Now, I dissuade against tracking down multiple crashes in parallel because you simply do not know if the crashes are caused by the same or different bugs. If it is caused by the same bug, you are just wasting time diagnosing the other crashes. If it is caused by different bugs, you have no idea whether the bugs interact with each other or not in causing the crash. Ideally, you want to find and fix non-interacting bugs in parallel because interacting bugs may not be real bugs after you fix the original issue (so you would be just wasting resources again). In short, tracking parallel can be complicated and the pay-off is not certain... you have been warned!
Yes, this is very similar to how the IIS product team approaches bug fixing during our stress/reliability test runs. We start up all IIS processes under the debugger and monitor it for any problems, and as soon as anything crashes/hangs, the debugger is already there so we can diagnose the first occurrence instead of waiting for a second occurrence. And as soon as we get a fix, we just crank everything up again under debuggers and wait for the next failure. Highly efficient and no wasted effort.
Conclusion
I hope that this helps clarify what is a crash on IIS and how to best deal with it.
Resist your natural urge to pattern match event log messages or failure codes to a solution, and do not be discouraged if you do not find your particular failure code or if others have similar but supposedly unsolved issues. Crashes are usually arbitrary and requires stack trace analysis to determine the real cause and the next step. If you do not use tools like IIS State or DebugDiag to catch the crash, you will rarely figure out the real culprit and the correct next step. Pattern matching is nothing more than a random guess, so do not take chances.
Personally, I always attach a debugger to gather a stack trace whenever I suspect a crash. Depending on your debugging skills, this can tell you a whole lot of info, sometimes sufficient to directly fix the issue. Guessing at solutions based on non-specific symptomes can never do this reliably. It is all up to you. :-)
//David
Thanks to David
Problems statements similar to the following questions pop up all the time on various IIS newsgroups, and the user usually claims that they have either seen (or not seen) many posts that look like theirs, and never any concrete solutions. I am going to try and explain the whole thought process, why things work the way it does, as well as useful next steps.
Question:
#1
Our production server has recently started experiencing AppPool crashes. These seem to occur sporadically. sometimes three times a day, sometimes not for a couple of days. The error manifests itself to the client as "Service Unavailable". In the system event log we see the following:
A process serving application pool 'DefaultAppPool' suffered a fatal communication error with the World Wide Web Publishing Service With error number: 8007006d
At the same time (but not always) we see this error in the Application Log
"Faulting application w3wp.exe, version 6.0.3790.0, faulting module kernel32.dll, version 5.2.3790.0, fault address 0x000249d3"
The application does usually start working again after anywhere between 2 and 15 minutes (although no worker process restarts or recycles appear in our perf logs).
This problems seems to have started occuring following the latest MS patches being applied to our server. It may just be a coincidence though.
We are running Windows Server 2003 Standard. We are about to apply SP1 in an attempt to solve this problem, but I wanted to find out if anyone else has had this problem and what the solution was. I have seen several similarish posts but nothing concrete as a solution.
I have seen this article (http://support.microsoft.com/Default.aspx?id=885654) but it doesn't quite match our situation as we are not running as a domain controller. We haven't yet tried running registry monitor as I wanted to find out if error 8007006d always equates to a registry permission problem?? before installing
3rd party freeware onto our production server.
Any help is much appreciated
#2
There is a similar question posted today, but the event ID is different
I see the following error anywhere from 2-3 times a day on Windows 2003 server.
Event ID- 1009, a process serving application pool 'Q' terminated unexpectedly. The process ID was 'xxxx' . The process code was 'xxx'
So far we have not noticed anything on the application side, but once in a while W3WP.EXE starts using up all the CPU and the server comes to a halt. This is not associated with the application pool terminating, but wondering if it is conntributing it.
I have applied SP1 for Windows 2003, that did not make any difference.
Any help is apprciated.
#3
Hello Together!
I've got a problem with my Windows Server 2003 SP 1 Web-Edition
If I look in the event Viewer, I allways find the following Error:
Event Type: Error
Event Source: Application Error
Event Category: (100)
Event ID: 1000
Date: 28.08.2005
Time: 22:00:26
User: N/A
Computer: {removed by the author}
Description:
Faulting application w3wp.exe, version 6.0.3790.1830, faulting module
Why does this error occur? What is it and what can I do to resolve this problem?
Please help me
Answer:
You are looking at what is commonly refered to as a "crash" or "access violation" on the server. To be clear, this is different from a "hang" on the server, though the web browser may appear to "hang" or the browser's icon motions for some time (the length of time depends on various network connection timeout periods as well as whether the server-side connection stays open or closed) before reporting some random error response relating to missing server, DNS, or other service error.
Crash vs. Hang
What distinguishes between a crash and a hang on the server? Ok, for the astute reader in the back, just be quiet with this simplification. We want folks to to internalize and understand the issue, not regurgitate dry documentation. :-)
Practically speaking, a crash is something that will simply wipe out its host process; this will stop whatever server side work and response generation that the process was supposed to perform. Now, prior to IIS6, this same process also held the connection open, so as soon as a user-mode crash happens, IIS will go down and the client browsers see a disconnected connection and usually report some sort of service disconnected/not-found error. With IIS6 Worker Process Isolation Mode, HTTP.SYS holds the connections in kernel-mode, so regardless if user code running in w3wp.exe crashes, the connection stays connected and IIS starts up a new process to handle future requests - so browser clients will NOT see a disconnection for a crash. Unfortunately, the request caught by the crash cannot be re-executed (suppose that request was a bank withdraw...) unless you implemented Transaction semantics, so any unsent response is lost.
A hang, on the other hand, will usually keep its host process around but the hang prevents any real work from being done. There are many possible ways to do this - user code can be waiting for a lock that never gets released, either because it was leaked or there was a logical deadlock or livelock, or it could be in a clever infinite loop, etc. Once again, any unsent response will never happen once your code gets hung.
As you can see, from the perspective of the client browser, both a crash and a hang on the server can prevent a complete HTTP response from being sent back, so they can LOOK similar. Add to the fact that browsers may have bugs that cause itself to either crash and hang, and sound security practices on the server should limit information disclosure of errors to the client... so I never use browser behavior or returned HTML to diagnose server-side issues - I always diagnose based on information from various server log files.
About Diagnosing AppPool Failures...
Unfortunately, there are multiple event log entries from IIS that indicate a "crash" has happened, so you cannot just key-in on any particular event ID for a resolution pattern. For example, the earlier questions illustrate two such events, and there are other related ones.
Now, we did not intentionally try to make crashes harder to diagnose by making them appear as different events. What is happening is that the W3SVC component of IIS and the user-code execution component of IIS run in separate processes which execute independently of each other, yet asynchronously pass messages back and forth to indicate status. Suppose something crashes the process responsible for user-code execution...
Sometimes, IIS first notices it when a ping response fails to arrive; other times, IIS notices that the process handle has gone away... and while IIS understands that these are both catestrophic events that should be reported in the event log, it maintains good system design by reporting them uniquely. It is the responsibility of any analysis layers on top of IIS to abstract such detailed reporting and present a logical "process crashed" information to the user so that they can take action.
Unfortunately, that analysis layer is frequently the user's brain, who may not be able to abstract the details... and gets confused. But hey, I do not think that IIS should stop giving the details. On the contrary, I think you just have to look at the problem harder. :-) Or complain loudly and get us to provide a better debugging tool (like DebugDiag...).
What is a Crash
You can consider a crash as an unrecoverable event that resulted from some bug in the program that is executing - in the case of IIS, it simply provides a thin process and support infrastructure for your user code to run. And a bug is basically a logical flaw that results in unintended behavior given some arbitrary set of inputs. Notice that the behavior is unintended, and the set of causes is arbitrary. This basically means that bugs can cause crashes that happen sporadically or periodically... all depending on the set of causes, which is arbitrary!
Now, since the set of causes to a given bug is arbitrary, I would also caution against trying to "fix" crashes by blindly installing hotfixes, Service Packs, or making configuration changes. Crashes are caused by bugs, which are logical flaws, and the only way to "fix" the situation is to either:
fix the logical flaw itself, which requires diagnosing the crash to figure out the root of the problem.
change software configuration to avoid the logic flaw causing the crash, which can also require diagnosing the crash to figure out what is causing the issue.
To make things even more interesting... a variety of logic flaws can cause crashes, all of which look the same from an IIS and event log entry perspective (to IIS, the crash ended the process; does not matter what; so just report it).
Thus, you may see similar looking events, sometimes with similar looking error codes, but no single concrete solution. The reason should be clear to you now - one flaw causing a crash with a certain error code is NOT the same as another flaw causing a crash with an identical error code. You are talking about two different flaws, and depending on the code path taken by your server configuration choices, you may need to do different things.
So, the take-away here is that the event log entry, the error code, and any other details you may discern are simply good clues to what is going on, but none are independently reliable for diagnosis. Treat them as pieces of a puzzle that you need to put together to correctly diagnose the issue, which is ultimately what you are trying to identify and resolve.
For example, I treat these events as simply crashes that need to be caught and their stack trace logs analyzed to determine further action. I would not immediately pattern match crashes to "solutions" without other information, and I certainly would not change any system configuration in response.
Frankly, I think it is rash for users to attempt to resolve their crashes without diagnosing the cause. However, most users seem to love pattern matching problem symptoms and event log entries with supposed solutions and blindly try them all, hoping some might work... all the while sinking deeper into some other problem due to their random changes. And the rationale should be clear now - if you do not know the bug causing the fault, how can you determine the configuration change to avoid that bug's path, or find the right patch to fix the bug?
How to approach the Crash
Ok, now that I have thoroughly trashed most people's usual methods of "dealing" with a crash, let me walk through another troubleshooting pattern on IIS. :-) I realize that you are probably under the gun to take some action to fix a problem, so you are willing to try anything and if it works, great; if it doesn't, then there is always product support or newsgroup/forums support to fall back on. I just want to propose a more actionable way to deal with a crash, so that you may be able to take care of things yourself... doesn't that feel good? :-)
Since you never notice a server crash until you interact with it (usually with a browser), when something unexpected happened and you do not think it is a bug in the application ("hanging" browser or server-error responses are reasonable clues), it is time to look for any signs of a crash on the server. When IIS6 runs in its default Worker Process Isolation Mode, you will see event log entries similar to the sort given in the questions - either IIS noticed the w3wp.exe handle signaled process exit/crash of some sort, or the w3wp.exe fails to respond to a ping, or Windows notices that a process crashed. In IIS5 Compatibility Mode, you will probably notice other event log entries, either saying that the IISADMIN or W3SVC service crashed and has done this for # times, or that dllhost.exe has crashed, etc. Anyways, all these events talk about something related to IIS crashing; you have no idea whether it is due to your code or not.
Now that you have identified that your issue belongs to a crash, it is time to set up debugging traps so that you can catch the NEXT crash and diagnose it. Yes, you heard me - you cannot do anything about the crash that has already happened - and since you have no idea what it is, you CANNOT change any server settings to avoid it. So, the only reasonable thing you can do is to set up debugging monitors like IIS State or DebugDiag on the necessary processes running code that is crashing and then WAIT for the next crash. Hopefully, you can trigger the failure condition easily, to shorten this wait.
On this next crash, these tools will produce a stack trace log as well as memory dumps to allow debugging, and you want to either analyze the stack trace log yourself, pay someone to perform an analysis (for example, Microsoft PSS) or post to a newsgroup like microsoft.publit.inetserver.iis to see if anyone will do a free analysis. Only after analysis of the crash can you determine what is truly going wrong
Hopefully, you only have one crash happening on your server, but even if there are multiple crashes on your server, you simply apply the same technique in serial. You catch one crash, resolve it, get a patch/fix, and run again with debugging enabled to catch the next crash, get it resolved and a patch/fix, etc... As developers will say, crashes are the most straight forward to diagnose and fix - they are truly the low-hanging-fruit of bad behavior on the server, so you should pick them off real early...
Now, I dissuade against tracking down multiple crashes in parallel because you simply do not know if the crashes are caused by the same or different bugs. If it is caused by the same bug, you are just wasting time diagnosing the other crashes. If it is caused by different bugs, you have no idea whether the bugs interact with each other or not in causing the crash. Ideally, you want to find and fix non-interacting bugs in parallel because interacting bugs may not be real bugs after you fix the original issue (so you would be just wasting resources again). In short, tracking parallel can be complicated and the pay-off is not certain... you have been warned!
Yes, this is very similar to how the IIS product team approaches bug fixing during our stress/reliability test runs. We start up all IIS processes under the debugger and monitor it for any problems, and as soon as anything crashes/hangs, the debugger is already there so we can diagnose the first occurrence instead of waiting for a second occurrence. And as soon as we get a fix, we just crank everything up again under debuggers and wait for the next failure. Highly efficient and no wasted effort.
Conclusion
I hope that this helps clarify what is a crash on IIS and how to best deal with it.
Resist your natural urge to pattern match event log messages or failure codes to a solution, and do not be discouraged if you do not find your particular failure code or if others have similar but supposedly unsolved issues. Crashes are usually arbitrary and requires stack trace analysis to determine the real cause and the next step. If you do not use tools like IIS State or DebugDiag to catch the crash, you will rarely figure out the real culprit and the correct next step. Pattern matching is nothing more than a random guess, so do not take chances.
Personally, I always attach a debugger to gather a stack trace whenever I suspect a crash. Depending on your debugging skills, this can tell you a whole lot of info, sometimes sufficient to directly fix the issue. Guessing at solutions based on non-specific symptomes can never do this reliably. It is all up to you. :-)
//David
Thanks to David
Subscribe to:
Posts (Atom)