Call me a scrooge but I've never called Microsoft PSS before because I didn't want to be hit with a bill for a bug in their software...

Today I finally tracked down a problem in my application which is a bug in IIS 5.1 / ASP.NET. The bug causes the wildcard ".*" Application Extension (which means all requests are passed to ASP.NET) to fail if the physical path of the ASP.NET folder contains one or more dot (".") characters...

This problem has caused me 2 days of heartache and while I'm glad I at least now know what the problem is... I now want a FIX!

So I go to MS Product support and choose the product where I believe the problem lies, "Internet Information Services 5.1". http://support.microsoft.com/selectindex/?target=assistance#I but I get:

Assisted Support for this product has either ended recently or will soon end . Please visit the Microsoft Product Lifecycle Web site for more information.

Try somthing else... The only version of the .NET Framework that is listed is 1.0 (does 1.1 not have any problems???) which gives me the same result...

So what now??

Has anyone here had experience with PSS? Is it worth going to the trouble, i.e. what are the chances of them actually providing me with a HOTFIX (thankfully I don't need to distribute it... )

Do you still have to pay even if the problem is indeed a bug in MS's software?

Marcus

If it's a bug, you don't have to pay. Even with win2k, they still will create a hotfix for you, 5 years after official support has ended.

What I'd do is this: call PSS, tell them your problem and that you think it's a bug in IIS or whatever MS product. They then will check that and get back to you. It might be a config error or something, so first google on it in google groups.

I'd never pay for PSS, and if its a bug you don't have to so it's worth a call I think . Most likely it's perhaps already fixed and they just mail you the hotfix url

Otis wrote:

What I'd do is this: call PSS

Maybe I'm missing something... but I don't see a phone number for PSS anywhere on the support site. Do you mean call the US directly or is there a local phone number list somewhere?

Otis wrote:

It might be a config error or something, so first google on it in google groups.

This is what cost me 2 days... it was a bitch to track down as few people are doing what I'm trying to do...

Otis wrote:

I'd never pay for PSS, and if its a bug you don't have to so it's worth a call I think . Most likely it's perhaps already fixed and they just mail you the hotfix url

But don't they ask you to give them a Credit Card number first?

Marcus

Marcus wrote:

Otis wrote:

What I'd do is this: call PSS

Maybe I'm missing something... but I don't see a phone number for PSS anywhere on the support site. Do you mean call the US directly or is there a local phone number list somewhere?

Hmm, I can only find: http://support.microsoft.com/oas/default.aspx?&c1=501&gprid=1248&

though as you said, the ireland site indeed just lists .NET 1.0, while the US site lists .NET 1.1.

Otis wrote:

I'd never pay for PSS, and if its a bug you don't have to so it's worth a call I think . Most likely it's perhaps already fixed and they just mail you the hotfix url

But don't they ask you to give them a Credit Card number first?

Not that I'm aware of, though they do ask for a product ID number. You probably have an MSDN universal subscription, so that definitely will be good enough for a call, as you get 3 or so for free.

Though besides that, if I'm not mistaken, I can search in the internal KB of MS as an MVP. I'll have a look.

Btw, isn't IIS 5.1 in Windows XP? 5 is in Win2k, 5.1 is in XP and 6 is in win2k3, if I'm not mistaken.

I've never actually had to pay for PSS, the last time I called in it took 2-3 weeks, 3 VS Developers and 2 VSIP guys to solve it and didn't cost me a thing other than my time in helping develop a work around solution for a VS bug.

John

I can't find anything (but that's no surprise, the KB search engine is blind, deaf and on a Vic-20 connected to the actual db) directly. Do you have an exact error message for me? I can search in the confidential articles (read: hotfixes made for partners) as well as the normal KB, so I might find something.

The only time I've used them was in a time-critical situation. They saved my bacon faster than I could research the solution.

I'd crashed a poorly-backed-up SQL server. They stepped me through a solution involving a re-install with certain parameters on the installer, and it worked.

I was sweating bullets, the customer was losing money, and I didn't have the time to read every stupid posting in Google. I was near throwing up, and the MS guy helped me through it.

For high-pressure situations they can't be beat.

Otis wrote:

Btw, isn't IIS 5.1 in Windows XP? 5 is in Win2k, 5.1 is in XP and 6 is in win2k3, if I'm not mistaken.

Yes that's right... development is done on WinXP which is where the problem is. I haven't tested Win2k3 yet...

Otis wrote:

I can't find anything (but that's no surprise, the KB search engine is blind, deaf and on a Vic-20 connected to the actual db) directly. Do you have an exact error message for me? I can search in the confidential articles (read: hotfixes made for partners) as well as the normal KB, so I might find something.

Thanks Frans... Unfortunately, there is no actual error... The problem is as follows:

In order to make all web requests hitting IIS 5.x to be processed by ASP.NET you have to set up a wildcard "application mapping". This is done by mapping the extension ".*" to C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll. (I need this functionality to enable URLRewriting where the URL folder structure doesn't exists on the file system and where I don't provide a "filename.extension" style document. I also can't use a custom 404 page since this seems to disable IIS compression)

(IIS 6.0 has a different mechanism for providing these mappings)

This works fine most of the time, but I have found that when an IIS virtual directory is mapped to a physical path that contains one or more "." characters, in my case "C:\ModernArk\Source Code\Branches\11Aug05\Sds.ModernArk.Web.UI" it stops passing requests to ASP.NET and simply reports a "404, File not found".

After some investigation I discovered that mapping exactly the same virtual directory application to a different physical path which is an exact copy of the above folder with exactly the same permissions, eg "C:\ModernArk\Source Code\Branches\11Aug05\Sds_ModernArk_Web_UI" works perfectly...

Therefore I can only conclude that the problem is with the dot characters in the physical path. This ONLY affects wildcard mappings, other mapping have no problem with the dot characters in the physical path.

If you see anything resembling this problem... let me know.

Cheers, Marcus

Here's one with EXACTLY the same problem: Google groups thread (still looking)

and this one Google groups thread might explain why it doesn't work. (I also might have misread it completely )

KB Article 834270 perhaps might help (or 829930)

Otis wrote:

Here's one with EXACTLY the same problem: Google groups thread

Wow... I didn't find this one!!!! Well done! Yes this is exactly the same problem... Don't you just hate newsgroup posts which end with the problem statement, not the solution! Well at least it confirms that I am not the only one with this problem.

Otis wrote:

Google groups thread might explain why it doesn't work. (I also might have misread it completely )

I'm not sure this is the same issue... I think this refers to the level at which the wildcard is specified rather than anything to do with what is and is not allowed in the path string.

Otis wrote:

KB Article 834270 perhaps might help (or 829930)

This is a curious one... I'm not convinced it's the same problem but it might be worth a try. It could be related or worse, a problem that I'm about to run into to

Either way I think I'll give them a call today and see whats happens.

Thanks for your help. (I still can't figure out how you found that first link above... )

Otis wrote:

KB Article 834270 perhaps might help

Just called PSS and this hotfix is already rolled up into 1.1 SP1

Marcus wrote:

Otis wrote:

Here's one with EXACTLY the same problem: Google groups thread

Wow... I didn't find this one!!!! Well done! Yes this is exactly the same problem... Don't you just hate newsgroup posts which end with the problem statement, not the solution! Well at least it confirms that I am not the only one with this problem.

Heh, yeah it doesn't help a bit, well, besides indeed that you now know it's not you.

Thanks for your help. (I still can't figure out how you found that first link above... )

No problem . It's a sport, trying to find something with the right keywords. Here in the netherlands they occasionally have a competition (held by a nationwide newspaper), where you have to answer vague questions which you can't possibly know so you have to search on the internet. These are a lot of fun, it will make you learn a lot about search engines

Marcus wrote:

Otis wrote:

KB Article 834270 perhaps might help

Just called PSS and this hotfix is already rolled up into 1.1 SP1

They didn't have a solution to your problem though?

Otis wrote:

No problem . It's a sport, trying to find something with the right keywords. Here in the netherlands they occasionally have a competition (held by a nationwide newspaper), where you have to answer vague questions which you can't possibly know so you have to search on the internet. These are a lot of fun, it will make you learn a lot about search engines

I guess we develop a "search style" and other people have different "styles" which allow them to find stuff you do not and vice verse.

Otis wrote:

Marcus wrote:

Otis wrote:

KB Article 834270 perhaps might help

Just called PSS and this hotfix is already rolled up into 1.1 SP1

They didn't have a solution to your problem though?

Well, I called about the HOTFIX but when I realised that it had already been rolled up into SP1, there was no point in trying it. A support call is £199 + VAT (€300+) while an email support request is £69 + VAT (€110+) so I opened a new email support request (in case I have to pay).

But now I'm sorry because the engineer seems to be in a very different time zone... His reply was at 4:30am. I have since sent a repro project so that they can see the problem for themselves. I'll let you know how I get on...

Marcus wrote:

But now I'm sorry because the engineer seems to be in a very different time zone...

Yup... I had a friend in MS look this guy up on their global employee list. The support engineer looking after my support request is based in "Shanghai"... What a bloody joke!!! That means it will take 2 days between my email and his reply.

OK... I'm gonna take bets on what PSS will finally say on this one

Here the latest email from them (note: after 2 days they still have not even tested it on the target OS "Windows XP - IIS 5.1"...)

PSS wrote:

Good news is that the wildcard script mapping can work on Windows 2003. The handler works fine in my testing environment. Based on my experience, IIS 6.0 has the different mechanism to handle the path from IIS 5.0/5.1. The behavior you found on IIS 5.1 may be a designed behavior. I will perform further research and update you when I have more details.

"may be a designed behavior" - you mean BUG...

So roll up, roll up, "Bug" or "Feature"... what's your bet...?

I'll go for feature . Also really lame they charge a lot of money for people who are in a timezone which is behind you, so you have to wait a lot of time.

And what is that person babbling about win2k3? . Like that's of any importance. On linux, it works different too, big deal

Otis wrote:

I'll go for feature .

You win...

Here is the response and workaround for anyone who is interested:

PSS wrote:

I reproduced this issue in Windows XP and have done a lot of debugging. I am providing you with some findings:

This issue happens in IIS5.0/5.1 due to the mechanism how IIS parses the URL request. When IIS handles the request, it tries to find an extension mapping. Because there is a wildcard extension mapping of this site, it will find the wildcard mapping when the request contains dot. IIS will try to build a physical path of the page from the URL. If the path exists and it is a directory, the IIS will treat it as malformed request and return HTTP 404 error.

The mechanism how the IIS builds the physical path is complicated. The result may be beyond your expectation. I understand that you may think it is a bug. In fact we met such kind of issue before when some Asian languages’ virtual directory name may be encoded as the string containing “.”. Unfortunately modifying this behavior is a big change in IIS and our product team will not modify this feature.

Based on my research, I am providing you with a workaround to make IIS not find the physical path and then IIS will go further to parse the URL:

1. Make sure the physical folder Sds.ModernArk.Web.UI.Test exists under c:\inetpub\wwwroot. The whole path should be c:\inetpub\wwwroot\Sds.ModernArk.Web.UI.Test.
2. You have created a virtual directory under root folder named Sds.ModernArk.Web.UI.Test which points to c:\inetpub\wwwroot\Sds.ModernArk.Web.UI.Test.
3. Then open a command prompt and go to c:\inetpub\adminscripts. Run the following command:

Cscript adsutil.vbs delete w3svc/1/root/Sds.ModernArk.Web.UI.Test/Path

1. Since we delete the path property, when IIS builds the physical path, it will combine the parent folder with the current virtual directory name. Because the current virtual directory name contains “.”, it will incorrectly build the physical path. Finally it will not find the physical path. Then IIS will go further to parse the rest of URL.

The above workaround may not be pretty but it works on my testing machine. I think it could be applied on your developers’ machines. For the production machine, I recommend you using Windows 2003 because IIS 6.0 has different mechanism to work with the URLs.

While the above workaround works... it relies on the fact that you have the web folder under the default IIS root "c:\inetpub\wwwroot\" which of course no serious project would have...

The solution is then to create UNIX style symbolic links between dummy folders in c:\inetpub\wwwroot\ and the actual folders containing the source code on your local hard drive. In Windows, symbolic links are called "NTFS junctions" and may be created using the linkd.exe utility found in tn Win2k Resource Kit or by downloading another tool from SysInternals called Junction (http://www.sysinternals.com/Utilities/Junction.html).

I have written a HUGE script which has automated all of the above so that when I pull source from source control onto a new machine, I double click the script file and it creates all the virtual directories, including wildcard mapping configuration, dummy folders, permissions and junction points... NIGHTMARE.

On the question of payment... Microsoft compromised on this:

PSS wrote:

It is glad to hear the workaround works. The bug is defined by our product team. I admit that the virtual path containing dot may not work as expected. I think it is not effective for us to argue whether it is a bug or not since the bug is defined by the product team.

I understand your concerns. I will set this case as non-decrement one for your satisfaction so that you will be refunded automatically. Then I will archive this case.

Marcus

What a crappy situation . So it's bad design from their part but they'll not fix that? Hmm.

Though, what I also thought of: you could remove the '.' from the folder names, or isn't that possible?

Otis wrote:

What a crappy situation . So it's bad design from their part but they'll not fix that? Hmm.

I guess they probably think that so few people will encounter this situation coupled with the fact that it's already fixed in a later version... It still pissed me off!

Otis wrote:

Though, what I also thought of: you could remove the '.' from the folder names, or isn't that possible?

Yes I could of course do this... but then my source code directory structure is not consistent. Which is the lesser of the two evils...