Jeff Sanders Technical Blog

I am a Microsoft employee that has worked on all aspects of the Web Stack for a long time. I hope these blogs are useful to you! Use this information at your own risk.


Earlier Posts

In desktop applications and services we frequently take System.Net traces to diagnose issues using the HttpWebRequest class, HttpListener, sockets, smpt etc… (and now the HttpClient classes).  We traditionally use the application configuration file (appname.exe.config) to enable the tracing.  The config file is read and the tracing parameters are used to trace the information we find useful.   Windows Store applications do not have configuration files however so you cannot use the application configuration file to take the trace.


Moved to our new blog here:


I was anxious to see what real memory usage would look like on my low end netbook.  It was better than Windows 7!  Less than 500M.  One problem I had was the native resolution of my netbook is1024X600 and the will not load Windows Store applications at that resolution.  I found a registry setting however to get higher non-native resolutions: “Display1_DownScalingSupported”.  As with any registry change make sure you back up the registry first before making changes.  I searched the registry and changed the value from 0 to 1 where I found it and restarted.  Now I can get 1024X768 and 1152X864.


I needed a simple WildCard Extension to remove a header and could not find one.  This needs a little more error checking code but can get the job done.  If you use it and add some enhancements or find problems, let me know and I will tune up the example!


If you build a WebBrowser control based application you will notice that Geolocation does not work properly. You do not get the prompt to accept the website “wants to track your physical location”. Because you do not get that prompt, you cannot accept this security prompt and you will not be able to use Geolocation.


I see some horrible solutions for this out on the web.  Most involve setting the proxy for the entire machine and then toggling it back off.  Here is a class that will allow you to set it ONLY FOR THE PROCESS that the control is hosted in.  You could call it like this:


I had trouble installing this update this morning.  I found that since I had installed the Windows 7.1 SDK as well, I had to first install Microsoft Visual C++ 2010 Service Pack 1 Compiler Update for the Windows SDK 7.1 KB2519277.  This seemed to allow the other update work fine!


OK, really not that secret.  Basic Authentication headers are pretty simple.  


Code that was working on a machine with the 2.0 (3.5) version of the .NET framework all of a sudden failed when this was flipped to the 4.0 version of the framework.  The end error was “The request was aborted, cannot create SSL/TLS secure channel” and “AcquireCredentialsHandle() failed with error 0X8009030D”.  This code imported a client certificate and key and was not using a client certificate stored on the machine.  I enabled CAPI logging and took traces of the failed and successful cases to compare.  Enabling CAPI logging:


Starting with Windows XP SP2, the Crypto API CRL check uses WinHttp (see: http://support.microsoft.com/kb/887196).  This can cause some confusion with network administrators and developers since they might have set proxy information for WinInet or applications using CryptoAPIs but the certificate validation fails for the https calls inside certain networks.


Creating a WCF Client in Visual Studio 2010, I struggled with this error.  I was running as the currently logged on user and the service was as well so this made no sense to me.  I found that this entry in the client app.config was the culprit:


There are two settings for WinHttp Proxy settings for a 64 Bit OS.  One applies to the 64 bit environment and one for the 32 bit environment.  You can use netsh for Windows 2008, Windows 7 and later OSes and proxycfg.exe for earlier OSes.  If you are confused and not sure where your WinHttp application is reading proxy settings from, the easiest way to determine where WinHttp is reading proxy settings from is to use procmon (process monitor).