About David


I recently decided to take a step back and looked around at some other blogs, and I realized that I had forgotten a very basic entry – a bio about myself. After all, who is this person that keeps writing Q&A about IIS and ISAPI in such a blunt (bordering on pedantic) tone, and can we get the guy to be nice and talk about something else? 😉

Well, I decided to author this blog for a very simple reason. I wanted to establish a singular identity and location to help people with their issues related to IIS and ISAPI. Believe it or not, I wager that there are only about two dozen distinct issue patterns (and obviously lots of sub-variations) related to IIS and ISAPI. So, I plan on posting categorical and clarifying answers for all of them. At least, this is my personal conclusion from answering questions on various newsgroups since late 2001, including IIS and ISAPI.

But believe me, I will definitely continue writing even after I tackle the distinct issue patterns. People are amazingly good at coming up with problems, and I am opinionated and enjoy giving feedback with my own insight. 🙂

Contrary to style issues, blogging and writing in first person is not a problem for me because I already keep a personal daily journal. So, you can say that this blog gets to have all the “technical” stuff while the “personal” stuff goes elsewhere. Oh, there may be some leakages here and there, but the brain works in subtle ways…

And before we get to far… let me first apologize and explain for my tone. When writing, I have a natural tendency to communicate with a tone that is logical, bordering on pedantic, and when you combine that with Q&A… I believe that the resulting message can be construed negatively. At least, that is what history has told me. But rest assured, I am NOT trying to be mean-spirited; I am just trying to help by providing information that I know.

Now, onward with the bio!

Before Microsoft

My first foray into working for hire was my junior year in high school, where for the next two summers, I worked at a local dentist’s office. I learned to do everything in the dental office other than operate on the patient, from receptionist to developing bite-wing X-rays, from patient data entry to handling insurance verification. Yes, it was a lot of random tasks, but back then, I really did not think of it that way. Besides, I got to do some data entry on an old 80286 machine, and scouring around DOS on that machine more than filled any of my idle time during the day.

I even remember the one time that I turned SmartCache on, thinking it would speed up the dental LOB database application… until a week later when the cache’s delay-write functionality and an unfortunate power outage caused some data loss and corrupted the database. Fortunately, the database had a backup and was recovered, but what I learned from this was the famous “if it ain’t broke, don’t fix it” rule – especially for finicky old computers.

After bumming around the entire summer following my college freshman year in Taiwan for “cultural studies exchange” (the Asians in the crowd should know what program I am referring to), I decided to get real and actually do summer internships. After all, the year was 1997, the Computer Industry and the Internet was all the craze, and I had declared Computer Science as my major.

I grew up in Houston, Texas, so my first internship following my college sophomore year was at a little computer hardware company called “CompaQ”. Not a lot of exciting stuff at that time other than NT4 and $7700 for a 512MB stick of RAM. My main takeaways from the internship were:

  1. I hate Commuting. I lived about 20 miles drive from CompaQ, but the daily commute took 45 minutes to cover that distance. It drove me crazy that I had to switch to really odd work-hours, leaving for work at 6am or leaving for home at 6pm. I can totally understand roadrage after a summer of this.
  2. Hardware is not the place for me. While I am glad at the opportunity to man-handle a lot of circuit boards, RAM sticks, and cables (I only had my own PC prior to this, so I was ultra careful at first, but after seeing the veterans go at hardware, my perceptions quickly changed), the routine quickly wore out. And most of the interesting stuff I had to do was related to performance benchmarks of various hardware, where once the hardware combo was assembled, it was all about software automation for testing, data gathering, and analysis/charting. I enjoyed that far more.

Then, for the next two summers, I interned at another little computer software company called “Microsoft” in Redmond, Washington. For those that have not interned at Microsoft… you are missing out. It is the epitomy of work hard, play harder. You stress out during the week, you unwind on Friday, and then you party all weekend.

During my second internship, I was a part of a little project called “duct tape” which consisted of a kernel mode driver called Universal Listener that parsed and routed HTTP requests to user mode processes, the XSP request pipeline was used to process requests, and a bunch of managed code modules loaded into this pipeline to implement IIS5-like functionality. Yup, you guessed it – the precursor to HTTP.SYS, IIS 6.0, and ASP.Net, but with much more managed code.

Yeah, for a time period, IIS 6.0 was actually a managed code web server running on top of ASP.Net – wrap your mind around that for a while. We all knew it was twisted – it took 10 seconds startup time to serve an initial static file (sound familiar, anyone?) – but something Drastic had to happen for the Right Things to happen and result in the current-day IIS process model in pure native code.

And for the astute reader that has been following IIS 7.0, it is a complete flashback to the 1999 days, where IIS functionality is implemented by modules running on top of a request pipeline that has full fidelity for managed code… except this time, I will wager to say, it is done right. IIS 7.0 goes out of its way to exclude managed code from being invoked unless it is absolutely necessary through configuration, so you get the best of both worlds.

At Microsoft

I joined Microsoft full-time in the summer of 2000, right after I graduated with my degree in Computer Science.

I joined the IIS team, and I started out testing ISAPI Filter API, eventually adding ISAPI Extension API to the mix, and with IIS 7.0, the new IIS Modules API. Hmm… a pattern emerges… this guy likes to test native code API that underlie core IIS extensibility. Well, I enjoy learning and figuring out how things work, plumbing and all, so this is my sort of challenge. 🙂

I also enjoy writing tools to simply make things “go” in the IIS team, including:

  • Automation framework and driver to install Windows OS and run any IIS test
  • Automation to actually locate and install all IIS tests, which are compiled and packaged as a real-world MSI nightly
  • MSI generation tool that automatically crawls over the daily build and creates a new MSI install package for that day’s test binaries/scripts/content
  • Virtual Machine integration so that installing Windows and IIS to run tests is the same on both virtual machines and physical machines

Yeah, I enjoy learning about various technologies, building automation tools exposing the best of their abilities, integrating them all together into a cohesive whole, and fulfilling team-wide processes. I am always looking for the “big picture” and plan appropriately.


So… this concludes a rather long-winded mini-essay… I promise to write shorter entries and lose less people’s interest. Really. 😀 Ok, so I can be a very long-winded person at times.

I hope you find the information that I am trying to share via the blog useful, and that you will take the effort to remark and debate. I do enjoy the challenge and want to help, but unfortunately, I am not psychic and cannot read your mind… so unless you disclose what issues you are trying to do with IIS/ISAPI, I cannot help…


PS: Yes, I will get back to the managed code extensibility of IIS 6 series now.

Comments (10)

  1. Harry says:

    Can you take a look at the thread on:


    Noone is answering this. Can you help? I am "harry" and can be reached at hstein@airmail.net or harry.stein@e-hps.com





  2. David S. says:

    Hi David,

    I am building an ASP.NET application for IIS6 that uses URLs containing query strings:


    I would my application to use the kernel cache. But it seems that ASP.NET will not use the kernel cache for URLs containing query strings. So I am looking for alternatives. I have some ideas:

    – use an ISAPI Extension that caches the response using HSE_REQ_VECTOR_SEND (which I assume can handle query strings). However, this will probably not work because the ISAPI Extension will not have access to the response sent by ASP.NET.

    – use an ISAPI filter to collect the response from ASP.NET using SF_NOTIFY_SEND_RAW_DATA and then cache it using HSE_REQ_VECTOR_SEND. This probably will not work since it is probably not possible to call HSE_REQ_VECTOR_SEND from a filter and it is also probably not possible to have HSE_REQ_VECTOR_SEND cache the response without sending it again.

    – use an ISAPI Extension that calls the dotNet application (ISAPI Extension calling dotNet application directly rather than through ASP.NET) and then cache the response using HSE_REQ_VECTOR_SEND. This seems like it would work but my application could no longer take advantage of ASP.NET.

    – use an ISAPI Extension that itself sends an almost identical Http request to itself so that the ISAPI Extension has a copy of the response and can cache it using HSE_REQ_VECTOR_SEND. Ugly, but it seems like it would work.

    – use an ISAPI Extension that stores the pointer to the request’s EXTENSION_CONTROL_BLOCK in a server variable and then use it from within the ASP.NET application to call HSE_REQ_VECTOR_SEND through interop. Wild!

    I would appreciate if you could let me know what you think would be a good approach.


    David S.

  3. David.Wang says:

    David – Yes, while HTTP.SYS/IIS allows querystring variation as cache-key into the Kernel Response Cache, ASP.Net does not. So, you have to find a way to have ASP.Net generate the response (so that you still have an ASP.Net application) yet capture that response and send it yourself via HSE_REQ_VECTOR_SEND.

    You have a good list of the possibilities. Of your five choices, the first two are not desirable.

    ISAPI Extension does not have access to any child URL response, and I am not a fan of the SF_NOTIFY_SEND_RAW_DATA approach because that turns off kernel response caching for other request types (like static file) and it synchronizes response output.

    The remaining three are variations of "ISAPI calls ASP.Net somehow, either directly, or through another internal HTTP request, or passing ECB to ASP.Net; privately buffer the response and send it with HSE_REQ_VECTOR_SEND." Since ASP.Net responses are buffered already, using that fact with the last two options would suffice.

    I think the coding is more clean-cut and simpler with the internal HTTP request approach, but the private ECB could work if you can get ASP.Net to suppress output and then send the buffered response yourself.


  4. David S. says:

    Thank you for your guidance. I took the last approach and wrote an ISAPI Extension that passes the EXTENSION_CONTROL_BLOCK pointer to AspNet. From AspNet, I can send a response using VECTOR_SEND through interop. This seems to work fine, although I feel a little uncomfortable calling a pointer that has been passed around as a string.

    My application needs to modify requests for several filename extensions so I originally used an ISAPI filter. This was changed to

    an ISAPI extension in order to be able to call VECTOR_SEND. The extension was installed as a wildcard application map. But I now realize wildcard application maps completely disable all kernel caching! I can’t imagine situations where it would be acceptable to disable all kernel caching. What use are wildcard application maps?


    Rather than using a wildcard application map, I am considering using an ISAPI filter in combination with an non-wildcard ISAPI extension. The filter would add a certain filename extension to certain requests, which would then be handled by a non-wildcard ISAPI extension. This extension would add the EXTENSION_CONTROL_BLOCK pointer header and change the filename extension so that the request would then be handled by AspNet. So much workaround!

    Thank you for your help.


    David S.

  5. Hi,

     I need some help on IIS5. Maybe you can advise me where others have failed.

     Im a Tech Manager of our company (mobile content provider). We have a windows 2000 server with IIS5 and serving files like polyphonic ringtones, wallpapers, truetones, mp3s, 3gp files.

     All content types could be downloaded properly through GPRS by our customers except for the big-size mp3s and 3gp files. By big, I mean filesize >= 600KB.

     When I download an mp3 using my Nokia 6600 with GPRS/WAP, I receive a "Server Timeout" error. Our business partners in Singapore reported the same thing to me when some customers complained that they cannot download the mp3s properly.

     Fyi, here’s the link:

     I uploaded the file to another webserver which is hosted by Godaddy.com but got the same result on my phone when I tried to download it. The link is:


     I hope you can help me.

    Best Regards,


  6. David.Wang says:

    Julius – your sample file downloaded fine for me with a normal PC-based browser.

    I suspect your problem is with the browser on the mobile phones themselves. I have been contacted by other mobile content providers having problems with serving "large" (>500KB) files to mobile phones, and their problems ended up being in:

    1. Network infrastructure between phone and web server. Some Proxies and GPRS/WAP gateways improperly handle and corrupt filestreams of various types.

    2. browser on mobile phone claims to be HTTP/1.1 but not truly HTTP/1.1 compliant and fail to handle things like 100-continue or chunked encoding correctly.

    None of these problems are with the web server. Depending on situation and actual issue, there may be applicable hacks on the client or server.


  7. I stumbled onto your page on Wednesday evening preparing for an

    intereview with Infospace on Thursday.

    However, with the amount of information and my limited knowledge of IIS it helped me a great deal during the interview.

    The end result, I was offered the job and I am very happy.

    I will certainly share your site with anyone who needs to be more proficient with IIS.

  8. David.Wang says:

    ornealm – Thanks for the acknowledgement. I am happy to help and good luck with the job! 🙂


  9. Ginger says:

    I am impressed by your blog and by your experience. I think David is an expert on Exchange and IIS.

  10. chandra says:

    Your blog posts are highly impressive.

    People reading your blog around the world. It would be nice if you are using simple english. Sometimes, I feel hard to understand your blog entries.

    Good work