I tend to be the type of person that likes to separate out the log4net configuration into it’s own file, usually log4net.config.  Setting up this new project; however, I started running into a problem I’d never seen before.  When trying to use the XmlConfiguratior to read my log4net.config, I would see this exception:

[SecurityException: Request for the permission of type 'System.Security.Permissions.FileIOPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.]

Searching for others with this problem has not yielded much success.  I’ve seen articles stating that it’s an issue with medium trust security (on m local workstation trust was set to full) to problems with some sort of breaking code within log4net itself.  Most of these articles I suspect were not using IIS7, but it was hard to tell.

I ended up digging into the log4net source code to find out what was happening.  The problem would occur on a line of code that tried to access the FullName property of a System.IO.FileInfo object.  That property threw the exception worked fine it I tried to access it from my web project, but once it got down into the log4net guts, it would not.

After a lot of frustration, I finally started looking elsewhere.  I ran across a comment on Stack Overflow that stated they used .xml instead of .config files.  I had dismissed it due since others claimed .config files where fine, but recalling what I’d seen there I decided to try it.  *Poof* it worked!

I didn’t really want to leave the configuration in a file with the .xml extension since that could easily be downloaded from a server.  The discovery told me that it was likely due to something IIS was doing with ASP.NET to hide files, but the odd thing was that it could read from the web.config, so I was a little perplexed.  I started digging into how IIS7 handles these types of protected files. 

It turns out that there’s a section in the hosting configuration that lists protected files under the name “requestFiltering”.  Hmm…that was an interesting sounding name.  Unfortunately all the entries were only by file extension, not by file name directly so there had to be something else.

I ended up in the IIS7 Manager application and found the Request Filtering area.  I began to poke around in there and discovered another tab called Hidden Segments which had an entry for the web.config!  I clicked the Add Hidden Segment link under Actions and added a new entry for log4net.config and viola, my application worked!

I know that most of the IIS7 configuration settings are stored in various config files, including the web.config, so I started looking in there and found this new element in the <system.webServer> section.

   1: <security>

   2:     <requestFiltering>

   3:         <hiddenSegments>

   4:             <add segment="log4net.config" />

   5:         </hiddenSegments>

   6:     </requestFiltering>

   7: </security>

I believe that including this section will allow the files to work.  I even changed my trust level in my dev environment to Medium and it still ran just fine.

There may be other things that can cause this sort of problem, but this fixed my example.  Hopefully this helps someone else out there as it was a bear to track down!

At work, I’m testing the 64-bit version of Windows 7 RTM as a developer workstation in our environment.  One thing that I constantly kept doing while making sure my environment is set up correctly, is looking for an application in the C:\Program Files folder.  Unfortunately, there are quite a few applications that are still 32-bit, so they get installed in C:\Program Files (x86) so I find that although I have a 50% chance to look in the right folder, I get it wrong about 90% of the time.  Wouldn’t it be great if there was a library that included both!  I decided to try it.

Right clicking in a blank spot in my libraries window gave me a New –> Library option.  Cool!  After giving my library a name (Programs) I found there was nothing inside, I went back and right clicked on my new library and chose Properties.  I was presented with a dialog that let me change a few things, such as adding folders the library should look into.  I added my two Program Files locations, closed the dialog, opened the library and viola!  There are all of my programs!  Very cool!

One thing I will briefly note, if this library is for a type of files that you will be actually saving files into, you can select the folder that acts as the default location to save files.  That way when you are in an application and you choose to save something, you can just click on the library and it will save in the default folder.  That’s not something you’re likely to do with programs, but there are other file types.  Another library I have added, for example, is Source Code.

They only thing that was disappointing at this point, was the fact that there was no option to assign a custom icon.  I did a quick search on Bing (I did a quick Google on Bing?) and found this guide regarding custom libraries.  It explained that libraries are really just XML files located in the special folder at C:\Users\<User>\AppData\Roaming\Microsoft\Windows\Libraries with some data describing the library.  One of the elements you an add to the library is called <iconReference></iconReference> which simply takes a path to an .ico files.  It does note that for the best results a 256×256 icon should be used, or an icon with appropriate sizes all in one file; however, I found one at 128×128 for my programs and it worked fine.

According to RFC2131 and the DHCP Options and BOOTP Vendor Extensions;

The router option specifies a list of IP addresses for routers on the client’s subnet.  Routers SHOULD be listed in order of preference.

That last bit was the key for working in our situation.  Our Windows XP clients grabbed the multiple gateway addresses and modified the routing table like this:

Active Routes: 
Network Destination  Netmask       Gateway    Interface  Metric
          0.0.0.0    0.0.0.0    172.16.0.1  172.16.0.40      20
          0.0.0.0    0.0.0.0  172.16.0.220  172.16.0.40      20

Both entries have the metric of 20, which was dynamically assigned by windows based on the link speed, the first entry is the one that was used.

We recently began testing Windows 7 in our environment.  We are fairly happy with most of the new features, performance and the overall experience in the new OS.  One thing that, so far, has been a great improvement is the new network stack.  With Vista, there were several issues including problems with unexpected freezes while network requests are made and problems with notebooks when trying to close the lid.  In Windows 7 most of those issues seem to have went away.

One minor issue that we did run across seems to be a bug, in my opinion.  When our Windows 7 clients processed the same DHCP requests as our XP clients, the routing table looked like this:

Active Routes:
Network Destination  Netmask       Gateway    Interface  Metric
          0.0.0.0    0.0.0.0    172.16.0.1  172.16.0.40      30
          0.0.0.0    0.0.0.0  172.16.0.220  172.16.0.40      30

Very similar results, just slightly modified metric which I can only assume is due to an updated algorithm for calculating the dynamic metric.  The only problem is that the second entry was being used as the default gateway.  We verified this on multiple Windows 7 clients.  It seems like it goes against he “order of preference” bit of the RFC.

It took quite a while and a lot of research, but I found out that Microsoft implements a vendor specific extension, 003 Microsoft Default Router Metric Base option.  The documentation for this value reads:

This value is a specified router metric base to be used for all default gateway routes used at Windows 2000 DHCP-enabled client computers.

This value can be assigned as an integer cost metric ranging from 1 through 9,999. It is used in calculating the fastest, most reliable, and least expensive routes. If a value is not specified, a default of either one (1) or the currently set interface-specific metric is used.

This is not very specific and for a while I did not think it would apply different metrics, but rather the same metric to all of the values in the 003 Router option.  I decided to give it a try regardless of my doubts and it worked!  Now, my XP route table looks like this:

Active Routes:
Network Destination  Netmask       Gateway    Interface  Metric
          0.0.0.0    0.0.0.0    172.16.0.1  172.16.0.40       1
          0.0.0.0    0.0.0.0  172.16.0.220  172.16.0.40       2

And my Windows 7 route tables looks like this:

Active Routes:
Network Destination  Netmask       Gateway    Interface  Metric
          0.0.0.0    0.0.0.0    172.16.0.1  172.16.0.40      31
          0.0.0.0    0.0.0.0  172.16.0.220  172.16.0.40      32

It is still disappointing that the DHCP routing options seems to be broken in Windows 7 (IMHO), and I am sure there will be plenty of people having similar problems when they begin rolling out Windows 7 clients in their environments.  Hopefully this article will save someone a little time trying to configure their Windows 7 clients to use multiple gateways.

While we were able to recover the file, some things just weren’t right.  The biggest problem ended up being with Windows Update.  When going to the site, it would simply hang on the part where it was checking your system for updates.

Investigation turned up mismatched versions of several of the wmi…. family of components.  Presumabl this was due to an incorrect file being restored by the system after the false positive event.  Trying to get it matched up correctly by had turned out to be problematic at best.

Finally I ran across an obscure post (sorry, I no longer have the link) where someone claimed that reinstalling a certain security patch from Microsoft fixed his problem.  After going through the re-installation of this patch on the first affected machine, it indeed worked!

The post referred to the MS09-12 securyt bulletin from Microsoft.  Most of the page refered to using Microsoft or Windows update to install the patch, which of course was not possible.  I was able to track down the direct download link for the file and I thought I would post it here for posterity.

Playback Device Properties

Yet another interesting change in the way Vista operations deals with the line in / microphone / various other possible audio input sources.  Vista apparently uses a software level driver to adjust itself for the source of the input.  One of the side effects of this is that the sound coming in from that source will not play through the speakers or headphone jack by default.

I say by default, but it is a little more complicated than that.  In Windows XP there was a setting in the playback device properties that allowed you to monitor the input, effectively playing the sound from the line in through the speakers or headphones.  A quick look in Vista shows that this option is missing.

Thanks to this post which pointed me to the Dell Community website, I was able to modify the registry.  My screen looks slightly different than the .NET Devhammer site, but the result is the same.

[EDIT]: Dell changed their community site around and I can no longer find the thread from above directly.  Thanks to Google’s cache I’ve tracked it down again.  The key you need to find is:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Class\{4D36E96C-E325-11CE-BFC1-08002BE10318}000\Settings\Filter\SpeakerHp\

(note: there are many entries with that GUID, you will have to look through each of them until you find one with the 000\Settings\Filter\SpeakerHp sub key)

You just need to create a BinaryValue name EnableInputMonitor and set the value to 01.[/EDIT]

One word of warning, after making this change you may experience serious feedback if you use a headset with a built in microphone.  I found that I must turn off the monitor function before plugging my headset in, otherwise it produces ear-splitting feedback that can be heard throughout my home.  I had not realized that headset could produce that many decibels!

Update for Windows Vista (KB995020)

It’s not so much that Microsoft feels it necessary to push out an update with five…yes that is only 5… words to the English and German dictionaries, it is the fact that it is flagged as important and that it may require a reboot!  The last time I looked, checking spelling has the option to add a word that has been flagged as incorrect to your local dictionary.  One button click is required to do this.  Uno.  Eins.  That’s it!  Yet, if I accept this update, according to the informational dialog, I may need to reboot!?  C’mon Microsoft!

I decided to read the knowledge base article for KB955020.  It shows me that the five words that will be added to the dictionaries are:

• Friendster (Is that a real word?)
• Nazr
• Obama (Oh c’mon, that’s a proper name!  Surely we can add that manually?)
• Racicot

KB995020 Article

Scrolling down in the article to the resolution section I see under Restart requirement that indeed I will have to reboot my computer.  Looking further down the page to the Workaround section shows me the Add to Dictionary method which I have already deduced.  The update itself just seems a bit unnecessary, don’t you agree?

In closing, beware of KB95502 from Microsoft Update as it may require you to reboot….all in the name of proper spelling.

The recent issue has been my headset jack. For a long time, each time I plugged something in to the microphone jack I would get the prompt from Vista asking what type of device was being connected. I would always leave the “Never Ask” checkbox unchecked just so I would have the ability in the future to easily use some other device.

The problem started about 2 weeks ago. I believe (although I don’t know for sure) that I accidentally checked the aforementioned option. From that point on I was no longer able to get to that dialog, and in addition my microphone would not work with some applications. Windows would indicate that it was hooked up and the level meter in the properties dialog would move suggesting that it was working; however, in applications like recording software and games using voice chat I would get no sound at all.

Searching around Google it turned out that many other people have had the same problem. The disturbing thing was that there are a lot of solutions (see the links) that solve the problem for some and not the others.

I tried most of the suggestions that I found with no luck. The one that sounded like it should work involved a check box that tells the driver to reset all popup alerts. That was a no-go as well.

In the end, there was a comment that suggested that reinstalling the driver would do the trick. I downloaded the latest from Dell (which was the version I already had installed), went into Device Manager (Control Panel -> Hardware and Sound -> Device Manager) including telling it to remove all files and rebooted. After doing so, Vista did detect my sound card and reinstalled the software. The next time I plugged in, viola! There was my dialog!

I don’t know if it is a Vista problem or a SigmaTel problem, but it is one that should be addressed. If you’ve found your way to this page and the reinstallation method does not work for you, try some of the other links from above. There are a lot of potential solutions, one of them may be right for you.

My previous experiences with Outlooks shortcuts and calendar lists disappearing popped to mind so I had him exit Outlook and rename his Outlook.XML file. Sure enough, it worked! When he restarted Outlook his To Do bar came back to life. He had to reset it to show the items he wanted, but everything has been fine since.

This is just another example of Outlook frequently corrupting a file it uses for UI settings. I still do not know why it seems to be so fragile. I have submitted my experiences to Microsoft but I do not know if there are any plans to make the process a little more robust. Given the importance of Outlook in today’s business world (for many companies at least) I hope that this issue will get the attention that it deserves. There are some in my company that are greatly affected by Outlook problems.

If you happen to see any weird Outlook UI issues, first thing to try, in my opinion, is renaming (and therefore rebuilding) the Outlook.XML. Good luck to all!

Just this morning I went through my installed programs list and removed some that I was no longer using.  It did free up some space.  Although I had plenty of space after this time I found an article from Greg’s Cool [Insert Clever Name] of the Day.  The title read “Don’t think you’ll need to uninstall Vista SP1? Want to recover up to a gig of drive space? Then check out the Vista SP1 File Removal Tool.“

At times I have to wonder what the odds are that the very thing I am doing or looking for shows up on someone’s blog post…but I digress.

Greg cited the post NicolBlog – “Window Vista SP1 File Removal Tool” AKA “how to recover disk space after Vista SP1 installation” . which described how to use the Windows Vista SP1 File Removal tool (Vsp1cln.exe).  After reading about the tool and running the instructions, I reclaimed almost 1GB of space as Greg suggested.  Thanks Greg!

OK, now that I’ve got that out of my system, I have to say that this has been one heck of a problem to solve, and that the search-ability of this topic is fairly low.

My problem arose a while back when my Windows Automatic Updater stopped updating automatically. At first it was not a big deal, I would simply use my browser to go to the Microsoft Update site on a regular basis. While this is a fine solution for me, I realize that for a large majority it is not.

I recently decided to install the Google Pack since I wanted some of the Google Software it contained and did not feel like tracking down the stand alone installers. After installing the “Google Updater” the software would tell me that the “Background Intelligent Transfer Service failed to start”. Looking in the Event Viewer I was presented with this information from the System log.

Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7023
Date: 2/13/2008
Time: 7:21:39 AM
User: N/A
Computer: JOEL2
Description:
The Background Intelligent Transfer Service service terminated with the following error:
The system cannot find the file specified.

Not very informative and, unfortunately, searching for that event ID and other bits of information was not very fruitful.

I finally came across the post How To Fix Windows Update (BITS/AU) after quite a bit of searching. Reading through this fine article by Mike I quickly realized just how many things can go wrong with BITS.

I began going through the list of things to try, of course verifying first if I needed to do a particular step. In step 2 there is a registry file to down and merge to try to fix the problem. I opened the file and looked through each setting to see if I needed to do it. It turned out that there was 1 setting I was missing. Parameters key was missing completely. Here is the part of the registry file that I ended up merging which fixed my BITS problem.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\BITS\Parameters]
“ServiceDll”=hex(2):43,00,3a,00,5c,00,57,00,49,00,4e,00,44,00,4f,00,57,00,53,\
00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,71,00,6d,00,\
67,00,72,00,2e,00,64,00,6c,00,6c,00,00,00

The ServiceDll value, converted to ASCII, is C:\WINDOWS\system32\qmgr.dll

After merging this my service started up and Google Updater worked great.  Thanks for the article, Mike!