Archive for the ‘Windows Vista’ Category

Changing where RDP Windows Open On The Screen

November 5, 2008 1 comment

Have you ever created a saved RDP session and found that it wants to open on the wrong screen or in a half-scrolling window?  It’s annoying, right?

After a random opening one in NotePad2, I realized the RDP files were simply text files of properties.  Easy enough; however, the values are absolutely painful to read through.

Here’s a snippet of the windowing properties:

screen mode id:i:1
session bpp:i:16

I’m assuming that the properties are in order of


“screen mode id” takes an “i” or integer and has a value of 1 (for windowed mode).
“winposstr” takes an “s” or string and has a value of 0,1,400,92,2500,992

“winposstr” sounds a lot like Window Position String, right?

After a bit of Googling, I found KB886187 which discusses each of the attributes; however, forwards you on to another article on MSDN regarding the WINDOWPOS (for winposstr).

Roughly, winposstr follows the following order:

0,[maximized = 0, windows = 1], [left], [top], [window width aka right], [window height aka bottom]

So, I prefer an 1152×864 window (as it fits nicely on my side 1280×1024 monitor), I’d set the desktopwidth and desktopheight to:


Now, my “main screen” is 1920×1200, so to get things on the right-side screen (which is 1280×1024), I need to move on the left PAST 1920.


  • 1970 is 50 (px) from the left side of my second monitor (1920 + 50)
  • 50 (px) from the top of the screen
  • 3138 (px) is 1970 (starting position) + 1152 (width of the window) + 16 for the window padding (thanks Randy!)
  • 960 (px) is 50 (starting position) + 864 (height of the window) + 46 for horizontal padding and the title bar

Now my RDP window always opens on my second monitor—just about in the center and looks good. πŸ™‚

Tweaking .NET Machine.Config For Production Deployments

September 17, 2008 4 comments

I recently rolled out an enterprise wide app to a pilot group (which, since pilots are silly or so I’m told, that means we rolled it out to EVERYONE or ~1200 users).  Not a huge amount by any means, but without a pilot, we didn’t have a good baseline to gauge performance settings.

I remember reading an article by Peter Bromberg ages ago about tuning IIS 6.0.  After a bit of Googling, I found it again and, one-by-one, started tweaking various settings on our development environment and hitting it with 500–1000 concurrent load users.

Here’s what I came up with that seemed to give the best bang for the buck.


      <add address=”*” maxconnection=”100″ />


maxconnections – This sets how many outgoing connections the ASP.NET service can make FROM the server, such as to databases, web services, etc.  Increasing this can increase the number of concurrent connections are available to your application.


    <deployment retail=”true” />

                clientConnectedCheck=”00:00:05″ />

                maxRequestLength=”10240″ />  


deployment/retail – Setting retail=”true” essentially forces all web applications on that machine to compile without debug.  This is extremely helpful for those rare cases that you forget to set debug=”false” on a web project.  In a production environment, debug files should rarely/never be needed, so this blankets the server.

processModel/autoConfig – autoConfig sets everything to the defaults except what I explicitly set below.  Just at time saver.

processModel/memoryLimit – This is a percentage of how much memory a web process can consume before it splits off into another process.  Since our production servers ONLY run IIS and web servers, then it should be safe to set this to 75% of the total memory on the box.

processModel/maxIoThreads – Based on Bromberg’s recommendation, this controls how many IO threads are allowed to the web process.  minIoThreads is the other side of the scale.

processModel/maxWorkerThreads – Based on Bromberg’s recommendation, this controls how many worker threads are in the pool for each web process.  minWorkerThreads is the other side of the scale.

processModel/clientConnectedCheck – An excellent setting that tells the server to check every 5 seconds to see if the client is connected.  If not, trash their queued requests (since they’re not there to receive it anymore).  According to this source, this also helps for those situations where users get “impatient” and machine-gun click the mouse trying to get a response.

httpRuntime/minFreeThreads – Based on Bromberg’s recommendation, a setting that tells the machine what the minimum number of threads in the pool must be in order for incoming requests to be processed.

httpRuntime/minLocalRequestFreeThreads – Same as the prior, but for the local machine (localhost)—good for locally hosted web servers; however, I’m not sure if it’s smart enough to know if “localhost” and a registered DNS entry are the same (I never refer to a machine as localhost).  It’s set, but more research required here.

httpRuntime/enableKernelOutputCache – This is set to FALSE for me, though most everything recommends true.  Why?  Kernel Mode caching is great—it’s speedy and a good way to speed up pages; however, we’ve had several issues in the past (on IIS 6) where it caused sessions to “merge” across authenticated users.  The issue is described here in KB917072.  Setting this for the machine just solves the problem overall.  Honestly, unless I can guarantee a way that the sessions/cookies won’t cross, I’ll give up a few milliseconds of performance in the day to guarantee a user experience.

httpRuntime/maxRequestLength – The default request length is 4096K; however, for uploading large file into the system, that becomes the limit.  A few of our applications allows users to upload documents, PDFs, etc. and attach them—we need a larger limit.  ~10MB seems to work well.  You “could” set this in the web.config; however, we base our production server at 10MB and then ramp up from there.

As with all tweaks, your mileage may vary—as mine does every single day.  I’d be interested to hear of other tweaks for higher performing web sites as well as feedback on the above (especially if I misinterperted a setting and simply haven’t seen the failure yet).

VS2008 and .NET 3.5 SP1 Success

August 12, 2008 Comments off

Danger, danger!Well, I’m 1/4 now upgrading the VMs to SP1.  The “one” that worked is the one I least expected.

Machine 1:

A simple VM used for a basic web project.  C#, Web Developer Tools installed—not even joined to the network.  No “hotfixes” were installed, but I ran the tool anyway just to be sure.  It chugged for a while and then threw an exception.  Feeling daring, I went ahead and tried to upgrade to SP1 and it didn’t even detect Visual Studio or .NET 3.5.  Hah.

Machine 2:

A prototyping VM that I copy web apps onto to run and test—nothing major, just VS2008, C#, web test tools, etc.  This one did have SP1 beta on it that I was dinking with as well as various Silverlight tools.  The patch removal tool worked just fine.  After a reboot, the SP1 installation got about 20% complete then McAfee (mcshield.exe) threw about 70 exceptions all at once and flooded the task bar.  The system then BSOD’d and reboot.  I tried another couple times to install SP1 (I can’t disable McAfee, ePO prevents it) with no success.

Machine 3:

This VM provides a test system for our customers to connect to, evaluate applications, and such.  VS2008 and .NET 3.5 (no SP1 beta) was installed more for convenience than anything else.  The system isn’t in use for the next few weeks, so worth a shot on this one.  I didn’t run the patch removal tool (perhaps that was my mistake) on this workstation and proceeded with installing SP1.  About 80% through the installation, devenv.exe crashed and asked to be debugged—of course, when I tried to debug, it crashed.  Hah.

Machine 4:

This is the one that worked; however, it’s the oddest, most broken of the bunch.  It’s had SP1 beta on it, various MVC preview builds, Astoria, bunches of Silverlight tools as well as various libraries and code bunches I have for newsgroup and forum posts.  The patch removal tool found a bunch of stuff and remove it without any issues.  After the reboot, SP1 installed (took about 45 minutes) and the system reboot.

And it works…

It works!

Seriously… why?

I still have a few VMs left to dink with and plan to throw it on my development workstation later this week after I wrap up a few projects and have some down time (I had planned to rebuild the entire workstation anyway—so good opportunity).

I hope, after I find some basic installation method, to have time to dig in to the features…

Review: ANTS Profiler 4.0 Beta

August 11, 2008 2 comments

A few months ago, I purchased ANTS Profiler 3.2 and have loved it.  It’s really helped me dig into some of my code, find performance hang-ups, and (I think) turn out better code and learn (it’s sometimes hard to find “do betters” in a single dev environment).

I played around with a few of the 4.0 builds and they were nice, but I honestly didn’t have time to dig into them.After a busy weekend, I sat down and spent some quality time with the 4.0 beta (b of ANTS Profiler and am blown away.


Installation was a breeze.  The 4.0 installer saw my existing 3.2 install and “upgraded” it; however, I was a bit surprised to find that the 3.2 sat side-by-side with 4.0.  That’s PERFECT, actually, and I hope they plan to keep it that way.

ANTS 4.0 -- Installed!

First Run Through 4.0

I’d like to start off by saying the new profiler startup UI is fantastic.  The prior “multi-step” wizard was great and easy to work through; however, I really like seeing everything on the first page.  Simply set the options and click Start. 

Profiler Settings - click for full image
(click for full image)

In addition, the quick access to additional performance counters, such as page requests and memory usage is really helpful.  I’m curious if additional performance counters can be added or if the list (see below) is the only ones handled by ANTS. 

Once things are rolling, the results come pouring in.  Just like with 3.2, 4.0 has detailed line level data—percentages per called line, hits, etc.  Very useful information.

However, the new call trees are sweet!  Why look at spreadsheets and lines when a graphical representation is available?  I have to find ways to boggle coworkers with these. πŸ™‚

My understanding is (I haven’t RTFM’d yet) is that the call trees display both your code (those that are bolded) and the managed code from .NET and called libraries (those that are tinted).

From here, I can see that a good deal of my slow down querying AD is coming not from the top level code, but from the Ldap code in System.DirectoryServices.Protocols and that the wait caused by that is the biggest hold up in all of Session_Start.

Another cool feature is the live performance counter view while you’re profiling.  This perfmon look into your application’s performance allows you to pause and checkout spikes (or unexpected dips) in any of the locked counters.

Counters graph.

To see the line-by-line details, simply drag the mouse along a section of the graph to select it.  ANTS will zoom in on just that area.  You can see the “highlighted” area below in blue.

Line Graphs, Zoomed In

That spike can be diagnosed in the line view—one of our methods is that doesn’t call very often (42 times) is taking a HUGE amount of time due to another that is calling 1000+ times.  Time to drill into that code and find a way to unloop it.


ANTS 4.0 seems quite a bit faster than 3.2 profiling the couple of .NET 3.5 web projects that I had sitting around in development.  In the past, I tended to avoid running ANTS against local Cassini projects; however, this kept up pretty well (though I think it does explain the LdapConnection latency).

It also appears that 4.0 can profile remote IIS instances (at least it doesn’t refuse it like 3.2 does); however, I haven’t quite gotten that working with the port settings (more to learn).

I haven’t hit all of the features yet, but I’m very impressed with the new look and feel, added “while you profile” live features, and the call trees. I can’t wait for the next beta and/or gold release—it’s looking good!

AnkhSVN 2.0 Released – How’s it look?

When I first started using Subversion full time for all of my personal projects, I stuck with the VisualSVN server and AnkhSVN as a Visual Studio client.  Both were free, easy to install, and easy to use.

However, after a few weeks, the AnkhSVN client could almost be called “annoying.”  It trampled over the existing SCC plugins for SourceSafe (for work) and made a mess out of several of my project uploads.  I ended up going back to using TortioiseSVN and doing everything through Explorer.

When AnkhSVN 2.0 was released, I figured I’d give it another shot.

The site claims quite a bit—including several unique additions:

  • Pending changes window; subversion status and commands available in one place
  • Full support for Visual Studio 2005 and 2008; AnkhSVN is now a SCC package instead of just an addin
  • Better log viewer
  • Merge support
  • Property editor
  • AnkhSVN now supports most project types previously unsupported via the SCC api
  • All solution explorer actions (rename, copy&paste, drag&drop) keep subversion history now
  • Enhanced build process and setup
  • Automatic check for updates
  • And last but certainly not least end user documentation

All of those look great—especially the SCC package and changes window.  But how does it compare once installed?

After installation and starting up VS2008, everything looks normal.

Brief Look

Pending Changes Window

The new pending changes window is FANTASTIC—much improved over the old 1.x versions.  I did run into a snafu when trying to resize the window where the scrollbars didn’t update on the screen; however, I’m not sure if it’s a VSS or AnkhSVN issue.

SCC Package

Under Options > Source Control, AnkhSVN shows up just like it should.

What does boggle me is that all of the Subversion commands and menus are available no matter what—even when the VSS SCC is enabled.  It still has the stink of VSS and SVN trying to step on one another (“pick me! control your project with me! no, I’m better! pick me!”).

Log/History Viewer

I really like the new history viewer.  It’s clean and easy to read; however, if you change the options at the top—there doesn’t appear to be a way to “change it back” and see the history again, close the view and review.


  • Opening a project from Subversion (File > Subversion > Open from Subversion) will open a project just fine, copy it down, but never opens it.  You have to go back and open the solution after it’s created the local structure.  Not huge, but annoying.
  • When viewing history; you cannot view the history of a single file (that I’ve found) in the Repository Explorer. 

I’m still planning to give it a whirl for the next couple of weeks and see what happens.  Hopefully over a couple weeks I’ll have more time to code—it’s been a busy July so far!

ReSharper 4.0 is now RC!

June 5, 2008 Comments off

The first RC for ReSharper 4.0 is out—pick it up! Nice!

Adding Multiple System Monitors ala Perfmon

May 22, 2008 Comments off

I use Perfmon a LOT. 

The logging and diagnostic software provided to us is, well, it’s just not that great.  Very slow to use and get around and every time I want a specific counter, I have to go ask for it because it’s someone’s “job” to add those. Ugh.  That’s no way to live.

Until now, I typically have a Perfmon console for each of my major application and SQL servers.  Why?  Because I was never smart enough to figure out how to add additional System Monitor controls into a single performance console.

Well, now I figured it out!

  • File > Add/Remove Snap-in
  • Click Add…
  • Select the ActiveX Control

ActiveX Control

  • A Wizard will start; scroll down and select System Monitor Control

System Monitor ActiveX Control

  • Give your new counter a name!
  • Repeat this until you’ve added your servers.  From there, configure each System Monitor control as needed.

Perfmon with all the servers!

From here, you can either add counters manually or use this brilliant PowerShell script.