The ASP.NET Sessions Active counter (NOT State Server) shows invalid number after installing .NET 3.5 SP!

in addition to the previous issue of random failing to install .net 3.5 SP1 in silent mode without restart, we had an issue of memory usage in load that we wanted to investigate and for that we requested from the load team to provide the Sessions Active counter of the INPROC sessions state.

Few days ago while we were analyzing the results we saw that the Sessions Active value was not related to any profile we use – we saw a very large number e.g. 4294967114 that started to occur after a very short period of time.

Also as a side note if by any chance you do manual collect you will see that every collection makes the number goes down, this is weird!

I started searching for this symptom and i have found similar issue in State Server Sessions Active counter which tells me that there is a bug that would probably be in another section of code – only time will tell (we use In proc session handling).

Today while speaking with TAM of Microsoft i understood that the issue is currently open and pending investigation by Microsoft, i will update once we have any progress here.

Do you have any clever way to get the number of sessions until the above issue will be solved – but without code :) ?

.NET 3.5 SP1 installation failed while working in silent mode and /norestart (random)

I have been struggling with an issue that we have seen our installation fails while installing .net 3.5 SP1 in silent mode (/q /norestart) on a windows 2003 that has .net 3.5.

The error that i have seen in %TEMP%/dd_dotnetfx35error is Microsoft .NET Framework 3.5 'package': [2] Error: Installation failed for component Microsoft .NET Framework 3.5 'package'. MSI returned error code 1603

while looking on more logs in the temp directory i have seen in %TEMP%/net_framework35_MSI[XXXX] error indicating that System.ServiceModel.Web is locked (inaccessible).

While working with Microsoft support i was told that although using quiet mode with no restart is written as supported it is actually NOT and the temporary documentation i got about it was this – blog post from Aaron Stebner's WebLog :(.

Currently i am trying to reproduce the lock under procmon to see which process actually locks it and waiting for an official KB article saying the above plus a solution for it (that will probably be to extract all the packages from the .net 3.5 SP1 and install manually.

for more info on the location of logs and general installation notes look here

I will update this post after i get final response

IE8 RC pops a message about bad search provider

I got the following annoying message after installing IE8 RC1

Internet Explorer - Search Provider Default
A program on your computer has corrupted your default search provider setting for Internet Explorer.

Internet Explorer has reset this setting to your original search provider, Live Search (search.live.com).

Internet Explorer will now open Search Settings, where you can change this setting or install more search providers.

 

I tried everything (change default, remove all providers) and nothing worked so finally I found the non trivial solution:

1. Delete registry - HKCU\Software\Microsoft\Internet Explorer\User Preferences
2. If it didn't resolve the issue then also remove the Google entry from registry from HKCU\Software\Microsoft\Internet Explorer\SearchScopes (make sure it's not default)

This will save you some headache