by Michael S. Kaplan, published on 2008/01/12 07:16 -08:00, original URI: http://blogs.msdn.com/michkap/archive/2008/01/12/7062458.aspx
From the recently pre-recorded blogs collection...
It all started with a security update.
Well, in this case, two security updates.
Both for ASP.Net:
Now with titles like that, of course they got uninstalled with the regular security updates at the appropriate "Patch Tuesdays" after the bugs had been found and the fixes were available.
But wait.
I should back up.
It actually started with a registry value name.
Well, in this case, two registry value names.
Both under the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel
and the two entries are:
I think those two descriptions that I just gave might give you some hints as to what comes next....
Bonus points for anyone who knows exactly what is going on and can prove it by explaining the case of the second setting!
Though just in case, I will show you a customer conversation on InteropCommunity.com related to SUA (Subsystem for UNIX Applications).
Well, in this case, two customer conversation on InteropCommunity.com related to SUA (Subsystem for UNIX Applications):
The question from a CLR developer several months later was:
I’m on the CLR team and we set both of these keys. Are they related in any way? Does obcaseinsensitive have any effect if the names specified in ObUnsecureGlobalNames are of the correct case?
Thanks,
And we did have some input from an architect as well, in reference to the actual problem that the ASP.Net fixes were looking to solve and the effect of just changing the registry key to something else:
...lots of other people would be very annoyed with the substitution problem that is mitigated by this setting.... Hint: guess which collates to be first in a case insensitive search: kernel32.dll or Kernel32.dll? Bonus question: what happens to the CLR's evidence rules if this happens?
Now of course since these updates were disseminated to everyone.
And when I say everyone, I mean EVERYONE (I have several non-server machines without IIS on which I have never been able to get a proper working install of ASP.Net, an issues that setup even warns about, which means I think anyone who got the .NET Framework has had these registry values tweaked).
In the end, it became KB article (MSKB 929110: A file system that was case sensitive becomes case insensitive after you install an update for the .NET Framework 2.0), which is meant to mitigate the way one Microsoft component (the .Net Framework) kind of danced up on the neck of another Microsoft component (Subsystem for UNIX-based Applications), leading to colorful threads like the ones I linked to above.
It may be a bit much to rejoice now, since the ecosystem here has been pretty badly trashed and even though (as the KB article states) the problem
Note This problem does not occur in updates for the .NET Framework 2.0 that were released after November 27, 2006.
Because as you probably know if you work with it, the registry does not keep history to know what the prior setting may have been in an easy to check and easy to rollback from.
The workaround information was also interesting:
WORKAROUND
If you intentionally set the value of the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\ dword:ObCaseInsensitive registry key to 0 because you must have case sensitivity for the file system, and an update for the .NET Framework 2.0 has set this value back to 1, set the value for this registry key back to 0 manually. Restart the system for the changes to take effect. For example, if the server is an NFS server in a heterogeneous environment and the registry key value is set to 1, you can set the value back to 0 manually.
Note If you reinstall the .NET Framework 2.0 or you repair or reinstall any .NET Framework 2.0 updates that were released before November 27, 2006, you will have to apply the manual workaround again.
You will probably notice that it only mentions repair or reinstall here, though several people who use SUA swear that even uninstall of the earlier patch requires them to do the workaround. And since most of the world that installs security updates had already installed this one long before it was fixed on November 27, 2006, there is not a whole lot of people who are spared the interesting side effects of the change
Plus it does negate a lot of the [formerly valid] advice I have given regarding case preservation like in the comments (not the blog itself) of No upproblems with $UpCase when you do a upVista upgrade and others.
Well, in this case, two KB srticles -- the explanation of the intent of the obcaseinsensitive registry value is explained in MSKB 817921 (Enable case sensitive behavior with Windows XP and Interix Subsystem or SFU), for those who are curious (and bonus points for anyone who notes the interesting problem/inconsistency in the article itself, which to give a hint is related to my previous offer of bonus points!).
It is slightly unfortunate (in my humble opinion) that none of the KB articles hint at what those two ASP.Net updates have done to the landscape of obcaseinsensitive.
1 - For example, my registry key on an XP SP2 machine with everything installed contained the following in its list: netfxcustomperfcounters.1.0, SharedPerfIPCBlock, Cor_Private_IPCBlock, Cor_Public_IPCBlock_)
This post brought to you by * (U+002a, a.k.a. ASTERISK)
# Phaeron on Saturday, January 12, 2008 5:16 PM:
I sincerely hope someone applied the bat to the .NET Framework team for this one. Solving an application-level issue by silently changing global system behavior is inexcusable.
# Michael S. Kaplan on Saturday, January 12, 2008 8:05 PM:
I personally find it to be a philosophical problem within the development of the .Net framework in general and the release of its security updates in particular.
It is deployed to everywhere (via new OS releases, via Windows Update, etc.) yet security fixes like the ASP.Net one and the locale name change one and the "UTF-8 conformance" changes are done without really taking platform level compatibility and ecosystem issues into account.
This one is perhaps the best example since it goes beyond just the internationalization space and impacts another [Microsoft!]product in a way that can potentially lead to apparent data loss and corruption, and the nature of the problem is such that there is no "fix" that is really feasible that would not potentially make the problem worse....
# Lionel on Wednesday, January 16, 2008 12:32 PM:
What is the situation in Vista, since both .Net and SUA are built-in components in some SKUs? Is obcaseinsensitive=0 supported? Does it still causes issues in ASP.Net?
I'm not sure I understand the ASP.Net issue, btw. Why is it sensitive to this setting, since Win32 always (well, except for FILE_FLAG_POSIX_SEMANTICS) forces case insensitivity, and .Net is built on top of Win32?
# Michael S. Kaplan on Wednesday, January 16, 2008 12:39 PM:
.NET performs some operations in ways that this setting affects, and then (similar to the way moving a SQL Server db to a case sensitive server can do it) a bug is exposed.
The mixup persists in Vista -- and is easier to see if you use SUA since the setting is so easily changed....
referenced by