I had reported an issue which happens after installing MS07-045 IE security update.
"After installing MS07-045 Cumulative Security Update for Internet Explorer - CreateObject call fails with 8000ffff "

We have a hotfix available for the same and it's KB 945701. KB is not yet available (as of today) and it might take a while to be public.

If you are struggling with this issue you can call PSS and request for the hotfix. It should be publically available during next IE patch schedule.

There are so many things which has changed in IIS7 for the better and one of them is about the way SSL works. Although IIS6 allowed kernel mode SSL (starting with Windows 2003 SP1) that wasn't the default option. As far as I know (AFAIK) not many customers used it or knew about it.

Starting with IIS7 kernel mode SSL is going to be the default setting and the only setting. This was primarily for performance reasons. So let us see how it differs.

IIS6 SSL request/response flow

IIS7 SSL request/response flow

You know that context switching between kernel mode and user mode is expensive and this new design of how SSL processing is done inside kernel mode increases performance on IIS7.

IIS7 Rocks!!!

We have noticed an issue of CreateObject call failure after installing MS07-045 IE update. This issues goes away if you uninstall the patch.  As per the information available it's happening only when .NET managed component (using interop) is called from an ASP page.

Error shown in the browser looks like below

Server object error 'ASP 0177 : 8000ffff'
Server.CreateObject Failed
/hellocom.asp, line 2
8000ffff

Repro steps given below

• Install MS07-045 security patch
• Create a .NET managed component (helloworld.dll)
• Make it COM visible and register it using "regasm helloworld.dll /codebase"
• Create an ASP page (inside your website folder) which calls this component using CreateObject (hellocom.asp)
• The page fails with the error mentioned above

For repro and testing I'm attaching following repro files

• helloworld.dll (managed component)
• hellocom.asp (which uses the above component using CreateObject call)

Code inside helloworld.dll

using System;
using System.Collections.Generic;
using System.Text;

public class HelloWorldClass
{
    public HelloWorldClass()
    {}

    public String SayHello()
    {
     return "Hello World";
    }
}

Code inside hellocom.asp

In my repro I get access denied for these registry keys for IUSR account

Till an official update is available on this issue, please run regmon and fix the permission issues shown in the logs. Please give permission to only the user account shown in regmon logs and not for everyone group since it would increase security risk.

For testing if the permission requirement is only for IUSR account, add IUSR account to administrators group and test. In my case it works and confirms that it's missing permission only for IUSR. This step is for only for testing and needs to be reverted immediately.

Uninstalling this patch is not recommended since it's a security update.

Although the title says webserver certificates the script is not limited to webserver certificates only.

This script is useful for admins to check expiry dates of server certificates and be prepared to renew or change them. In case if you have ideas of using this in your server environment and you need help in tweaking this script do let me know.

Please copy & paste script below into a file called "CertExpiryCheck.vbs" and run the script from command line like

C:\> cscript certexpirycheck.vbs [SubjectName]

C:\> cscript certexpirycheck.vbs sukak

* here "sukak" is subject name which usually would be your domain name (FQDN)
* Issued by also shows "sukak" in my case since the test was done using self issued certificate created using selfSSL.exe

'**************************************************
'* CertExpiryCheck.vbs
'* Enumerate certificates with day left for expiry 
'**************************************************

Option Explicit
Dim SubjectName
If WScript.Arguments.Count > 0 Then
    SubjectName = LCase(WScript.Arguments(0))
Else
    CommandUsage
End If

Dim Store, Certificates, Certificate
Const CAPICOM_LOCAL_MACHINE_STORE = 1
Const CAPICOM_CERTIFICATE_FIND_SUBJECT_NAME = 1        
Const CAPICOM_STORE_OPEN_READ_ONLY = 0

Set Store = CreateObject("CAPICOM.Store")
Store.Open CAPICOM_LOCAL_MACHINE_STORE, "MY" ,CAPICOM_STORE_OPEN_READ_ONLY
Set Certificates = Store.Certificates.Find(CAPICOM_CERTIFICATE_FIND_SUBJECT_NAME, SubjectName, 0)

If Certificates.Count >0 Then
   For Each Certificate in Certificates
    'Certificate.display()    'If you want to see the Cert in UI
    WScript.Echo "*** Subject " & Certificate.SubjectName & " ***"
    WScript.Echo "Issued by " & Certificate.IssuerName 
    WScript.Echo "Valid from " & Certificate.ValidFromDate & " to " & Certificate.ValidToDate 
    WScript.Echo "Days to expiry " & DateDiff("d",now(),Certificate.ValidToDate)
    WScript.Echo 
   Next
 Else
  WScript.Echo "No certificates with SubjectName => '" & SubjectName & "'"
End If

Set Certificates = Nothing
Set Store = Nothing

Sub CommandUsage
  MsgBox "Usage: CertExpiryCheck.vbs  [SubjectName] ", vbInformation,"CertExpiryCheck"
  WScript.Quit(1)
End Sub

Just keep in mind you need capicom.dll to use this script. This comes default on Windows 2003 (I guess) but might need to be downloaded and registered on other platforms like Vista. Use regsvr32 capicom.dll to register it first before using the script.

When I was a developer (I mean employed as a developer, even now I develop applications, don’t get me wrongJ) before joining Microsoft, I used to get stuck with application issues; whether its process crashing, process not responding or high memory usage. There were not many options for me at that time but to review code for that page or form and figure out the cause myself.  

If there was a tool which I can use to tear the process and see what is going on inside the process I would've saved a lot of my hours (or maybe days). Although Windows Debugging Tools (WinDBG) was available, it was not too easy to learn the commands or understand how all those stuff works when you have development timelines/deadlines (or is it death lines?) to be met. 

Not many developers are aware of what kind debugging I’m gonna talk about. When ever we talk about debugging people assume that it’s live debugging using Visual Studio or so and put breakpoint and walking through the code. Huh! This would be a blessing if we can do the same thing in case of production servers, but on production server applications it’s a completely different ball game. 

Think of a situation where customer has an issue on production box with IIS process(Here IIS process is used just for illustration but below explained issues are true with any other multi-threaded process/service) My Options (being little bit sarcastic)

1. Send windows source code to customer and we will install Visual Studio to walk through the code and find what the issue is” You know I would loose my job. J
   This kind of debugging works mostly for client applications
2. What happens if I don’t really know when the issue happens?
   I can employ a person who will sit in front of the server 24x7 watching for the issue to happen
3. What if the issue happens only for sometime and the issue vanishes?
   By the time my monitoring person yawns, the issue would vanish
4. What happens if the issue only happens when a specific user sends a post request with some specific string in there which leads the IIS process to get stuck and block all requests?
   Start writing “Debug.Print” or “Response.Write” kind of tracing to find out where it gets stuck. You might not finish your project anywhere in near future 
5. Customer called on my mobile and is screaming because my website is not responding.
   I need to run to the server (maybe even drive, since the server is in a remote place) to take a memory dumps.

DebugDiag or Debug Diagnostic Tool is not the 1st tool but as far as I know would be the 5th generation of tool for doing post-mortem memory dump analysis. Most of those previous tools were were exclusively used by PSS and were not available on Microsoft Downloads.

Post mortem debugging simply means that we take a snapshot of the process memory when the issue happens and use either DebugDiag or WinDBG to figure out what was going on inside the process when the issue happened and find out the cause for the issue. Since this is technically challenging, it takes a lot of time. Some of our customers think that it's like looking into iislogs to find the request. Let me tell you that its mostly digging deep into thread stack, heap and other memory areas to find out what might’ve lead to the issue. 

What is Debug Diagnostic Tool?

DebugDiag is a post mortem debugging tool which has analysis capabilities, so in simple words there is 3 parts for this tool.

1. Capture memory dumps for different types of issues (Hang/Crash/Memory)
2. Run basic analysis on the captured dumps and generates a report to understand the results. It also provides very good pointers to issues mostly for expert eyes.
3. Exposes an object model which can be used to easily access the information available inside the memory dump file (memory dump file extensions are usually DMP / PDMP / MDMP)

1. Debug Diagnostic Service (dbgsvc.exe)
2. DebugDiag UI (debugdiag.exe)
3. DebugDiag Host (dbghost.exe)

Debug Diagnostic Service
This is the service which is the heart of DebugDiag. Why should it be a service? In the past we used AD+ (Auto Dump+) for troubleshooting most of those debug scenarios. AD+ is executed from the command line and client side program. This simply means that it runs under the context of the logged-in interactive user.  

Let’s take an example. Assume that we are trying to track an issue which happens intermittently, say for example process crash and it happens once in a week or month.  

So we setup AD+ (KB 286350) from command prompt. Since this tool runs from command line if you logout from the console AD+ stops monitoring. So if your organization has multiple administrators who look after the server they need to be informed not to logout from the console till we track and get a good set of dumps for the issue. This becomes extremely difficult specially because we find out that someone did a logout only after the next issue occurrence and by then its too late. Then we start monitoring again and sleep till we get another repro. Keep in mind, in some cases a repro might take seconds, minutes, hours, days, weeks or even months. 

Another issue with AD+ like tools is that you cannot use it through Terminal Service sessions which most of those administrators are too used to J AD+ provides a lot of customization options and its powerful in that way, and it was “the” tool we used in the past (and I see people using it even now). To get around the above mentioned issues DebugDiag runs as a service as “Local System” so that it’s not dependent on the logged on interactive user session.  

So how do we configure this service since windows services cannot have UI? 

DebugDiag UI
DebugDiag user interface is used to create rules for capturing different types of issues by creating rules and also the interface to run the analysis portion of the tool. 

DebugDiag like I mentioned before (did I mention?), has a scripting host built-in using which we can customize and extend the features according to the requirements. The main script file called “DbgSVC.vbs” (we call it as controller script) is present in scripts folder inside installation folder. This script gets modified when you make changes in the UI related to Hang or Memory Leak rules.  This script file contains (or exposes) some events which you can use to extend and customize the working of DebugDiag. 

Open the Controller Script (“DbgSVC.vbs”) in notepad and see for yourself. 

Rules are nothing but simple way of configuring DebugDiag to work according to your requirements for specific scenarios. Rules contains information about the location where you want the memory dumps files to be stored etc and also contains Events you can further use. For example if you create Crash Rule, DebugDiag creates a script file called “CrashRule_IIS.vbs” in the scripts folder. 

Open the Crash Rule Script (“CrashRule_IIS.vbs”) in notepad and see for yourself. 

Now with DebugDiag you loose the functionality like we had in AD+ to run it from command line. Do we? Not really! Continue reading… 

DebugDiag Host
So how do I know what’s available under the hood?

Go to Command prompt and type
C:\>dbghost /? (Obviously you should try from the installation folderJ) 

I can analyze the dumps myself? Oh really?
DebugDiag provides analysis feature which you can use from the DebugDiag UI tab called “Advanced Analysis”. By default, right now we have scripts available for analyzing “Crash/Hang Analyzers” and “Memory Pressure Analysis”. 

Analysis Scripts are nothing but .ASP pages inside “Scripts” folder which uses somewhat ASP kind of scripting style and uses VBScript to iterate through the structures inside the dumps (which is nicely exposed using an object model) and try to find out known issues or easily identifiable issues so that for simple issues troubleshooting can be done by yourself without calling MS PSS. 

More to come which includes Script customization, specific steps to be taken for scenarios like Hang/Crash/Memory related issues etc...