Kristof Rennen’s Blog

After moving to Windows 7 a few days ago, I already found a great new feature which allows users to virtualize applications from a Windows XP machine to a Windows 7 machine.

By using this new feature, users have the possibility to install Windows Xp only applications, and run them from their Windows 7 desktop right away.

In this post I will show you how you can get this kick-ass feature up and running. Please take into account, that this feature is still in beta at this moment.

Getting The Stuff

To get this feature up and running following downloads are needed:

• Windows Virtual PC Beta
• Windows XP Mode Beta

To be able to use this features, your computer should support Hardware Virtualization which can be enable or disabled in the BIOS setup.
More information can be found here.

Installing The Stuff

Nothing special is needed to install both the Windows Virtual PC Beta and Windows XP Mode Beta.

Windows 7 asks you to reboot your computer after the installation of the first application, but you can just continue installing the second one without any problems.

The installers will create 2 separate directories:

• Windows Virtual PC
• Virtual Windows XP

The second directory looks more or less like a regular Virtual PC 2007 directory:

The Windows XP is installed into a .vhd file, which is also used when using Virtual PC 2007 or Virtual Server.

Starting It Up

When you first start up the Virtual Windows XP, you are asked for a username and password which will furthur on be used to automatically login to the XP machine when needed.

The status of the Virtual Machine can always be checked using the dedicated Virtual Machines directory. You can see the name of the machine, its status, assigned memory and primary disk location.

By double clicking the machine in the list, it is started automatically:

When the machine has finished booting, you have a clean Windows XP machine to work on:

Virtualizing Applications

To tryout the application virtualizing, I will be using Firefox since I don’t install this on my windows 7 since I’m always using IE8 ;-).

The first step to take is installing the application inside the virtual windows xp as any other regular application.

That’s all there is to it. The application has now been installed inside the virtual windows xp, but can now be virtualized from within Windows 7.

If you open the start menu of your windows 7, there is a new folder containing all the Virtual Windows XP Applications:

Starting A Virtual Application

Any virtual application can now be started directly from the Windows 7 start menu. Before an application can be started, the running virtual machine needs to be closed down.

Also when you want to start up the virtual machine, all virtual applications need to be closed down, so its always one of them both running.

If you don’t close down the machine, you will be prompted to do so when you start up an application:

When starting the application, the virtual environment gets initialized.

After the initialization has completed, our virtual application is running and can be used as any regular application.

Conclusion

Virtualizing applications on Windows 7 really is a powerful and easy to use mechanism to run incompatible applications.

I already needed it once to be able to install some software which was incompatible with both Vista and Windows 7 even when using the available compatibility modes.

Kristof Rennen Software Microsoft, Windows 7

Last week I finally got rid of my windows vista on both my home computer and my computer at work, after suffering from too many problems for too long.

Even though Windows 7 is still a Release Candidate, I took my chances and installed it on both my machines.

I must say I’m really happy with the change. Everything is running smoother than on my vista machine without any problems.
Certainly network access and file operations have been improved a lot, which is certainly handy if you have to move or copy a huge amount of files.

I will certainly post about Windows 7 in the future, after some more experimenting.

The final version of Windows 7 will be released to manufacturing (RTM) in the second half of July and will be in stores on the 22nd of october.
I really can’t wait to make my final upgrade to Windows 7 in a few weeks.

Kristof Rennen Software Microsoft, Windows 7

The last few days have been great for the Microsoft Surface in belgium.

Last sunday, VTM used a Microsoft Surface during the election show, to visualize the results.
You can read more details in my previous posts:

• VTM Goes Surface
• Microsoft Surface At The Belgian Elections

On monday VTM already launched its second surface application:

 

This application is used to browse and manipulate belgian newspapers and magazines during the late news.
In the following weeks / months, this will be a fixed item in the late news to show the headlines of the next day in the same format as the real printed papers.

With those 2 applications, VTM really gave the surface a great start in Belgium. Let’s hope a lot of great application will follow in the future.

Kristof Rennen Development Microsoft, Surface

In my previous post I already mentioned VTM using a Microsoft Surface to give an overview of the 2009 election results.

There is already a video available, posted by Luc Van de Velde of Microsoft:

Kristof Rennen Development Microsoft, Surface

Yesterday, elections took place in Belgium.
As with any election show, TV stations always do their best to impress people watching as much as they can.

VTM chose to use the Microsoft Surface during their show as the first one in belgium using this new technology for a real purpose.

The application itself consisted of 3 scenes used by the presenter to go through the results as they were gathered throughout the day:

• A startup scene
• A coalition scene
• An evolution scene

The startup scene

The startup screen showed the logo of “De Stem Van Vlaanderen”, the same one as used on the plasma screens behind the presenters.

The coalition scene

This scene was used to navigate through all the possible coalition combinations between the 7 big factions.

An overview of all factions is shown, which can be expanded or collapsed showing the total number of seats reached by that faction.

By dragging the faction itself into a pie, 3D pie pieces visualize the possible coalitions.

The evolution scene

This scene is used to show the evolution of factions and cartels between the elections of 2004, 2007 and 2009.

By dragging the title of the faction into the bar below, the results of that faction are shown.

By using different discs the results from all the factions could be visualized in an interactive fashion.

This shows us how nicely a Surface can be integrated into any environment, and according to me the application really looks nice so they gain my vote

Let’s hope they will come up with various nice applications in the future.

Kristof Rennen Development Microsoft, Multi-Touch, Surface

In my previous article, I talked a little about the inside and outside of a Microsoft Surface unit. To actually start developing Surface applications, a few more steps are required.

Prerequisites

• Microsoft .NET Framework 3.5
• Microsoft Visual Studio 2008 with C# Project features
• Microsoft Windows Vista 32 bit
• Microsoft XNA Framework Redistributable 2.0 (available here)
• Microsoft Surface Development Kit (not publicly available)
• A minimum screen resolution of 1280 x 960

Creating projects

After the installation of the prerequisites is done, extra templates have been added to Visual Studio to be able to create new Surface projects.

 

There are 2 options to create a new Surface project:

• Using WPF
• Using XNA

I will be choosing WPF now, so when the new project is created a basic structure is foreseen which looks like this:

Following files are already available:

• A first surface window
• An app.xaml to initialize the application
• An application xml file to describe the application (description, name and icons)
• Some resources

Running projects

There are 3 possibilities to run a Surface application:

• As a standard windows/wpf executable
• On a Surface unit itself
• Inside the Surface simulator

Any Surface application can be started as any regular wpf/windows application by double clicking on the executable, or by hitting F5 inside Visual Studio.

The application will then look like this:

The second way of running a surface application, is by running it on a surface unit or inside the surface simulator.

Surface Simulator

The surface simulator is an application installed when you install the Surface sdk. It simulates a multi touch device, by supporting multiple mice, tags, … anything which is supported by a real Surface unit.

The simulator can be found here:
C:\Program Files\Microsoft SDKs\Surface\v1.0\Tools\Simulator\SurfaceSimulator.exe

When multiple mice are attached to the computer, they can all be used to interact with the application although working with multiple mice on a single computer is not really easy

If you are like me running on a screen resolution less than 1280 x 960, you will receive following error message unable to run the simulator. I’m going to try to find a solution for this so I can develop surface application on my laptop as well.

To run the application inside the simulator, you have to make sure the simulator is running before you start the application. When the simulator is running, and you start the application using the executable or by hitting F5 inside visual studio, the simulator will show the application:

Conclusion

Now that we have our environment set up, we can start developing our kick ass Surface applications. The development itself is more or less the same as WPF development. Only a few controls have a specific Surface control which needs to be used (SurfaceButton, SurfaceCheckbox, SurfaceWindow, …)

An important tip when starting with surface development is not only relying on the simulator to test the applications. It’s really needed to test the application properly on a real unit as well since the interaction with multiple people around the application is a lot different than running it on a single machine with multiple mice.

In the coming weeks I will be posting a little more on my experiences while developing one of our Surface applications, so stay tuned.

Kristof Rennen Development Microsoft, Multi-Touch, Surface

As of today, we are working on a Microsoft Surface application which gave me the idea starting to blog about news, features, nice to knows, … anything you may want to know about the Microsoft Surface and the development of Surface applications.

In this first article, I will be talking about the Surface in general, and what it is all about.

The Idea

Microsoft Surface fundamentally changes the way we deal with digital content on a computer.

Instead of working with a dull mouse and keyboard, which is not very intuitive to all users, we will be using our hands and fingers to operate the Microsoft Surface.

We can grab data with our hands, move it around by performing simple gestures, and this even with multiple persons simultaneously.

All computers only have a single input device which is the mouse. The surface on the other hand is a full multi-touch device, supporting up to 52 touch points (that are a lot of mouses).

The Outside

The Surface itself it built as a small table, where the plate itself is the multi touch device.

Because it looks so natural, it can easily be included in various surroundings.

The surface of the Surface, is a kind of matted glass material, feeling really soft to the fingers, and allowing fast movement.

The viewing angle and brilliancy of the screen is made so a lot of users can have a clean image, when surrounding the table.

The Inside

The inside of consists of 3 major parts:

• Near infrared camera’s
• A computer
• Rear projection system

In total, there are 5 camera’s monitoring the surface for movement tracking. The reason Microsoft uses 5 camera’s, is to solve field angle problems. Each camera monitors it’s own small area of the surface, resulting in better speed and resolution. It was also needed to get the table as low as it is now.

The camera’s themselves can read unlimited numbers of touch points on the surface. The limit of 52 is only set because of CPU processing limits.

The computer inside the Surface is a high-end machine, but runs on mainly conventional components. It is powered by a Core 2 Duo 2.13 Ghz CPU, and has 2GB of RAM.

The Operating System on the surface computer, is a standard non-modified Microsoft Windows Vista operating system. An extra layer is running on top of this windows vista, called the shell.

The read projection system, projects the computer’s image to the underside of the tabletop.

Communication

The Surface offer 3 ways of communication:

• WiFi
• Ethernet
• Bluetooth

There are already sample application using the WiFi possibilities to automatically load content from a wireless device, if put on the Surface.

Development

To develop Surface application, there is a choice between Windows Presentation Foundation and XNA. Custom WPF control have been built to support the Surface specific interactivity.

The development can be done using the Microsoft Surface SDK, which integrates with Visual Studio 2008 and allows the developers to run a Surface Simulator to test the application locally on a windows vista machine.

Technical Specifications

Size: 108 x 69 x 54 CM
Weight: ca 90kg

Network:

• IEEE802.11b
• IEEE802.11g
• Bluetooth 2.0
• Gigabit Intel Network Adapter

I/O:

• 2 headphone jacks
• 6 USB 2.0 ports
• RGB component video
• S-VGA video (DB15 external VGA connector)
• Component audio
• Ethernet port (Gigabit Ethernet card [10/100/1000])
• External monitor port
• Bays for routing cables
• On/Standby power button

 Display:

• Type: 30-inch XGA DLP® projector
• ATI X1650 graphics card with 256 MB of memory
• Maximum resolution: 1024 x 768
• Lamp mean-life expectancy: 6,000+ hours

Computing System:

• 2.13-GHz Intel® CoreTM 2 Duo processor
• Memory: 2 GB dual-channel DDR2
• Storage: Minimum 250 GB SATA hard-disk drive

More Information

More information can be found at the following locations:

• The Official Website
• The Surface Blog

In one of my coming articles, I will be talking about Microsoft Surface Development.

Kristof Rennen Hardware Hardware, Microsoft, Multi-Touch, Surface

In my two previous posts, How An ASP.NET DataBind Can Cause A Memory Leak and How An ASP.NET PostBack Can Cause A Memory Leak, I showed you how a UserControl inside a Repeater could cause serious memory problems.

Well after working on the memory issues for several days already, a co-worker of mine finally found a solution to ensure all user controls and pages are disposed properly.

Davy explains how he solved our problems in his blog post about the topic: Guaranteeing Disposal Of UserControls In ASP.NET

 Well, thanks to Davy’s great technical knowledge, we finally managed to get the memory in this application and all our future applications stable, proven by a rerun of our stress test scenarios.

Thanks Davy!!

Kristof Rennen Development .NET, ASP.NET, Memory, Microsoft, Profiling

In my previous post How An ASP.NET DataBind Can Cause A Memory Leak, I talked about how I suffered from serious memory leaks in my current project, because of some user control not being disposed when doing manual databinding multiple times.

After being really happy about my tedious quest being finished to fix the problems, I today noticed the memory leak still occurred in exact the same location, but when using the functionalitity in another way.

The case is still the same:
Page -> UserControl -> Repeater -> UserControl

So the loaded page of the scenario, contained a user control of our own. This user control had a repeater, repeating over the rows of a generic list, creating another UserControl for each found row.

Every row, rendered through the ASP.NET Repeater, has 2 buttons available:

• A button to edit the given row
• A button to delete the given row

The button to edit the given row is not giving me any problems. When I click it, the user gets redirected to the edit page and everything gets cleaned up pretty well.

The delete button on the other hand, is performing a postback on the same page, calling an event to handle the delete:

Ofcourse this delete event is doing the following stuff:

• Getting the row’s id from the CommandArgument
• Calling our business layer to delete the record
• Performing a databind to reflect the changes

It is the last action, which performs the databind, which is now triggering the memory leak … again.

The problem

By doing a postback when clicking the button, a new instance of my user control with all it’s needed resources is created.
Because I’m doing a DataBind() at the end of my “Action”, a second instance of the same user control with all it’s resources is created, leaving the first one undisposed forever.

The second one though, is being disposed properly and does not give me any problems.

The only explanation I would have for this kind of behaviour, is that it all happens inside one postback cycle.
Probably if a control is then created multiple times, only the last one gets disposed at the end of the cycle, leaving the other ones up to the Garbage Collector.

In our case the Garbage Collector is not of any use, since the user control has references to other undiposed objects, causing all those objects to remain in memory and causing a memory leak in the end.

The solution

Well, to be honest I don’t know a proper solution right now and I will probably need some time to figure out a proper way to fix this.

If I add the databind, the application is suffering from a memory leak, which is totally unacceptable.
If I remove the databind, deleted records are still shown on my page, which is totally user unfriendly.

I’ll keep you posted if I find a proper solution, and I then hope ASP.NET is not going to disappoint me ever gain.

Kristof Rennen Development .NET, ASP.NET, Memory, Microsoft, Profiling

Currently I’m working on an ASP.NET application for one of our customers. The application is nearly finished, and is going to be put in acceptance and production in a few weeks.

To test the scalability of the application, stress and load tests are run using Visual Studio Team Test at our side and Load Runner at the customers side.

The stress tests are all running well on both sides, except for some weird OutOfMemory exceptions after a run of 9 or 10 hours with 100 concurrent users. The scenarios are built to simulate one month of work in 10 hours.

Setting up the environment

Since the application consists of a front end and backend, it was important for me to setup my IIS properly to enable me to find whether the problem was caused in the backend or frontend.

The backend application, is a WCF service host, running inside IIS. The frontend application is an ASP.NET application consuming the backend through WCF services.

The running both the service host and web application in a separate application pool, I was able to monitor both separate worker processes to narrow down the problem to one of the two.

Finding the cause of the OutOfMemory exceptions

Before one can start fixing the cause of the OutOfMemory exceptions, you first have to find the cause of course.

Using windbg, DebugDiag and DotTrace, we started investigating the memory usage and patterns of the applications finding that the allocated virtual memory was exceeding the IIS limit, causing OutOfMemory exceptions and unexpected pool recycling.

It was clear the application was suffering from a memory leak, which could still be a native or a managed leak.

A great source to find more information on tracing, Windbg, … is the blog of Tess Ferrandez, an ASP.NET Escalation Engineer of Microsoft. Her blog really helped me out during my search for the cause of memory leaks, and by analyzing all the memory dumps I created.

Reproducing the memory leak

Before one can start fixing the memory leak, its best to have a scenario to easily reproduce the problem.

We started by creating a scenario using a lot of functionalities from the application. By running this scenario we could easily reproduce the problem after a run of a few hours.

By narrowing the scenario down, up to a single functionality only, I was able to trigger the high memory usage faster and find the location of the bottleneck in the application.

I now had an easy way to reproduce the problem, and to verify the fix afterwards.

Tracing the memory usage

Since I now had a scenario which I could use to trigger the memory leak, I used JetBrains’ DotTrace profile to profile my IIS while running the scenario.

Everytime I ran the scenario, I noticed some ASP.NET UserControl not being released from memory. Since this user control, had references to other components as well, those components were “leaked” as well.

By using the trace output, I now had the name of the user control which was not being disposed properly.

The actual problem

The actual problem was a page containing a user control with the following structure.

Page -> UserControl -> Repeater -> UserControl

So the loaded page of the scenario, contained a user control of our own. This user control had a repeater, repeating over the rows of a generic list, creating another UserControl for each found row.

Since we are using ASP.NET with the Model-View-Presenter pattern (to be able to develop everything Test-Driven), we were calling the databind of the view manually as follows:

First we DataBind() the user control after its properties have been set. Then we call base.DataBind() which does a DataBind() of the complete page.
Ofcourse the DataBind() of the usercontrol is not really needed since it will be automatically called when you DataBind the complete page, but hey it should not cause any problems either.

Since the memory profile told us the user control was not properly cleaned up, we just put a breakpoint in its constructor and dispose method.
Analyzing this really blew us of our seats. The constructor of the user control was called twice, but the dispose method was only called once so we were stuck with one instance of the user control for ever. Hello Memory Leak!

The solution

Solving the memory leak was in the end easier than we should have imagined. By just removing the UserControl.DataBind() did the trick.

The DataBind() of the page now looks like this:

Conclusion

I ran my stress tests again together with my DotTrace profiler and everything seemed to be working ok. The memory leak was fixed, and the memory usage of the application was back to normal.

Currently a new run of the stress tests are both running on our environment and our customer’s, but I’m really confident the memory leak was fixed.

Now that I had this memory leak by just using functionalities from ASP.NET, I’m not sure if it is like this by design or that it is really a problem in ASP.NET itself? I hope to find an answer soon, but in the meanwhile I call it dirty behaviour of ASP.NET itself ;-).

Kristof Rennen Development .NET, ASP.NET, Memory, Microsoft, Profiling