1. Get and install and then start WinDbg
2. File - Open Crash Dump
3. ~*kb
   Lists all the threads and their call stacks.
4. !locks
   Will show you the critical sections. LockCount - RecursionCount - 1 = the amount of times the lock has been acquired.
   So if you have several locks that are taken you can check the call stacks and see where you have the deadlock.
5. !runaway
   Will show you time spent in each thread.

I find it useful to get a text dump of all the call stacks which I can search in my text editor, rather than clicking around using Visual studio when searching for a deadlock.

And sometimes !locks even saves me the search.

But if I want to inspect variables I load the dump into visual studio.

Common WinDbg commands here.

If you have an application built on pre .NET 4.0, you can’t use Visual studio to debug a dump file. Even if you can use Visual Studio, WinDbg offers a nice alternative and some extra features in some scenarios. For example help finding deadlocks and a faster way to scan a lot of threads.

Getting started with managed (.NET) debugging using WinDbg. Just follow these steps:

1. Get and install and then start WinDbg
2. Open Crash Dump
3. .loadby sos mscorwks Loads the .NET extension
4. !clrstack Shows the stack of the current thread or use ~* e !clrstack for stacks for all threads
5. !threads shows a list of the managed threads
6. ~19 s selects thread 19
7. !dso dump all objects on the stack
8. !do dump object
9. !da dump array

Example:

If I open a crash dump and run:

• .loadby sos mscorwks
• !clrstack

in my case I see a stack that ends (or begins) with System.Net.Sockets.Socket.Receive or something else that tells me that it is a request thread and in the application I work with, such a call is associated a Simple.Communication.Path. Then I run

• !dso (shows all objects on the stack)

and in the output I search for Simple.Communication.Path I find a Path object on the stack with address 22fd77b4. I hope this is the path requested. to show the value I run:

• !do 22fd77b4 in the response I find 22fd77ec systemAbsolutePath so I run:
• !do 22fd77ec it shows (among other things): String: /Top/Servers/AS5/Trend Quantities/Internal Logs/Interval Trend Log 10_copy_7 So there I have my path.

Make it easier

To make it easier, download the SOSEX extension and copy it into your windbg program folder (WinDbg is also xcopy deployable)

• .load sosex Loads the sosex extensions
• !mk –a Lists the current thread with locals and parameters.

You will find the path from above formatted as a string ready to read as an argument to one of the methods on the stack. Find out more about SOSEX here. Another SOSEX favorite:

• !dlk shows deadlocks

to find out more about for example investigating memory leaks look in the readme.txt that comes with SOSEX.

Another extension

I just recently found out about a new extension Psscor2 from Microsoft. Download it, put it in your WinDbg directory and load it:

• .load psscor2
• !help

And play around. Have fun.

More Information

Here you can find the basic commands needed: SOS Cheat Sheet If WinDbg doesn’t find the symbols, look here: Resolving symbol problems in WinDbg

When Bob the tester comes, and tells me that the client application sometimes hangs for about 30 seconds, when Bob is doing nothing. This client, and a hand full of other clients are connected to a system of connected servers. The problem could be a busy server or some internal client problem. We have to find out what the client is doing when it get’s busy, for no good reason.

My first idea was that perhaps Bob could use the feature in the task manager in Vista and Windows 7, right click on a process and select Create Dump File.

Automate it?

It would of course be better if we could automate it, it’s not that easy to select a process, right click and choose the right item within 30 seconds.

So then I found a good tool for generating dump files when a windows application is none responsive.

The tool is ProcDump from SysInternals.

ProcDump is a command-line utility whose primary purpose is monitoring an application for CPU spikes and generating crash dumps during a spike that an administrator or developer can use to determine the cause of the spike. ProcDump also includes hung window monitoring (using the same definition of a window hang that Windows and Task Manager use), unhandled exception monitoring and can generate dumps based on the values of system performance counters.

I have used it to catch the cases where TheClient hangs for a number of seconds.

To use it in this case:

1. Start TheClient
2. Run ProcDump with the following command line:

"procdump.exe -h -ma TheClient.exe TheClient.hang.dmp"

It will then generate a dump file in the current directory when the application shows as "Not responding". Then it’s just to bring out WinDbg to find out what was going on.

Our session at TechDays 2010 gave an overview of what storage in the Cloud is, according to Microsoft at present date, and some of the goals for the future in this area. We intended our session to provide the basis for companies to be able to evaluate if and how moving storage to the Cloud can enhance their business for their own specific scenarios.

Speaking about Cloud storage and Microsoft today means you need to give a session divided into two parts; SQL Azure and Windows Azure storage. And so our presentation had two distinct parts.

As consultants working with different clients we see that companies in general are not yet ready to adopt Cloud storage on a broad scale. However we also see a continuous increase in interest in this area and we believe that this is directly related to the richness of the offerings and services now becoming available. The story matures in the Microsoft camp and the pace is rapid. Cloud storage from Microsoft is admittedly still very young. (Youngest in the business?) But now Microsoft has thrown the full weight of the company behind making the cloud story stick. Expect to see a lot of new offerings, services, products, frameworks etc. in the Cloud coming out from Microsoft in the near future.

There are a few common concerns when it comes to storing data in the cloud. A quick (and perhaps not complete) listing follows:

Storage cost in the Cloud

One big concern we hear from clients and in the buzz at conferences that take place around now is a concern related to the cost of storage and data transfer in the Cloud. This is naturally an equally important issue regardless in what Cloud you choose to store your data.

The thing about storing your data in the Cloud is that the cost for this storage is a lot more self evident compared to storing your data in your own servers on premise. This is because you receive a bill each month stating exactly what you have spent for storage in the passed period. What we tend to mitigate is that storage, backups, crash plans and managing all of this on premise, or even hosted, does not exactly come for free either. The big question then becomes what difference in cost there will be for your company for storing and transferring data to a Cloud compared to local hardware operated by your local IT department.

Another aspect of the cost for storage in general is the question of how you build your apps. We believe that many have been a bit oblivious to this issue when they have run their apps and stored our data only on premise or with traditional hosting. Perhaps we have been cost inefficient in this area until now? In the age of Soft Deletes - deleting data does not remove it but rather marks it as deleted – no data is ever actually deleted - managing costs for storing data will become a more and more important question for everyone. Building Cloud applications and storing data in the Cloud has to be done with data storing and management costs in mind. As we hinted to above; the same should have been true for all of your applications up until now. Storing data in the Cloud just makes this point more obvious.

Storage Security when your data in the Cloud

Perhaps the fist fear when it comes to storing data in the Cloud is the fear of security breeches and the perceived loss of control of this security. Your data is no longer at home.

What you need to ask yourself, and here we choose to quote a good colleague Sergio Molero @sergio_molero, is; “What sense of security do you have today? What security is it that you think you will loose when storing your data in the Cloud?”

The same exact thing can be said for hosted data as compared to data stored in the Cloud because the two concepts are very much the same thing in this regard. Data in the Cloud is also hosted data!

One important thing to also keep in mind is that moving to a data storage solution in the Cloud does not mean all of your data must move “out there” somewhere. It is still quite possible to store the most sensitive data on premise and use Cloud storage for more public data only. We believe that the higher focus on security for data in the Cloud will put higher focus on your security efforts compared to your present security on premise. The move to the Cloud could in conclusion prove to heighten the overall security level for your data.

Also look into Windows Identity Foundation (WIF) for insights on how to secure your data in the Cloud.

Trusting someone else with your data in the Cloud

If security from external attacks to your data in the Cloud is a concern you feel somewhat confident you will be able to handle then perhaps trusting someone else with storing your company sensitive data is a concern that causes you to think twice? Trust is a complex issue not to be taken lightly. We will only raise the concern here and not delve too deep into it.

Can you trust a hosted data storage provider today? If you can, then this is no difference compared to trusting data stored in the Cloud.

If you can’t trust anyone else with your data, then the Cloud is not an option for you. Clean and simple.

Legal ramifications for storing data in the Cloud

It feels important to also comment briefly on the potential legal ramifications for storing your data in a Cloud in another country somewhere. That being said we’d just like to point out that we are no lawyers. Let’s be clear on that.

Some data cannot legally be moved outside the borders of your own country. Hospital patient information is a good example of this. Other data must for legal reasons stay within your geo-region, say for instance the EU.

As we hinted to above; not all of your data has this limiting concern. You do have more public data as well as more private data in your business. Only the latter is a potential legal problem. There will be more hybrid solutions for data Storage in the future. Some data for a company will be stored in the Clouds and other data will be stored on premise.

But how can we store data both on premise and in the Cloud without having two separate data storage solutions? One thing that will assist in this endeavor is the rumored upcoming availability of local on-premise, or hosted, Clouds that will be possible to install locally and behave in the same way the big Clouds out there on the Internet do. Right now there does not exist many offerings of this nature. There will in time when companies start to demand them. In fact, given that the storage Clouds today has a REST interface, it is not very difficult to implement that same interface on your own on premise machines! Doing this however will require a good effort on your part and you will end up with a proprietary solution that you will have to evolve over time as the real Clouds shift. Another option is to wait a bit and let the Cloud vendors come up with packaged solutions that you may install simply install in your own data centers. The hybrid solutions that will result from this will play an important role in shaping the solutions for data storage for the coming decade.

SQL Azure

In our SQL Azure part of our talk we pointed out three pros and three cons for attendees to take away from our session.

1. Because Windows Azure takes care of all of the maintenance normally associated with a SQL Server server developers are now allowed to focus on the database rather than performing administrative tasks.
2. The database is always available in the sense that upgrades are seamless as well as failover, backup and crash plan which means that the SQL Azure database is always available.
3. The scaling story is very strong in SQL Azure. If you can shard your database into many pieces you can scale out from one database to many (say 100) databases to meet a peek load and then back down again to just one at will. For now there is no built in support for this in SQL Azure but this will likely be a story further down the road and you can build it your self today.

There are some things to consider when looking into deploying to SQL Azure.

1. Security is locked down compared to SQL Server. The sys-tables are not yet available for instance. This is because your databases are co-located on the same servers as data belonging to some one else.
2. Your data is no longer at home in the sense that it is moved outside your company and even outside your country.
3. The size right now for one database in SQL Azure is 10 GB but this will increase to 50 GB in June.

Windows Azure Storage

With Windows Azure Storage Microsoft addresses a set of data storage stories that do not really fit well into a standard relational database structure.

1. There is a powerful and “infinite” message queuing system that enables messaging between the different machines in your applications. This queuing system does not guarantee 100% ordering of the messages in the queue. This is in case of more than one machine working on the same queue. However the queues require dequeue (GET) and delete (DELETE) in order to complete an actual removal of a message. This method will ensure each message will actually be handled in full in case of some error when decueing and handling the message the first time.
2. There is also a concept in Windows Azure of that which is known as a “Big Table”. Say you want to store 200 million user data sets for Facebook or why not all the messages ever sent to Twitter. For this you need an “infinite” tabular structure that has no end that you will ever hit.
3. The third thing you can store in Windwos Azure are two kinds of blobs. 1) A so called Block Blob. A blob that is handled in blocks when uploaded. A block Blob is not really intended to be changed once uploaded. You can exchange blocks in the blob but that is not the intent. This is typically a video file or a picture or something that is rarely if ever changed. You would use block blobs to build the next youtube where you can stream files down into a player. 2) A Page Blob. This kind of blob is divided into pages rather than blocks. You can real or write pages at will into this kind of blob. This means that you are able to create a Virtual HardDrive (VHD) and upload it as a page blob to Windows Azure. Then you can actually mount this blob to one or more virtual machines in Windows Azure as an extra hard drive. This comes in handy when moving an application to Windows Azure that uses a lot of disk. All of your old File.Open will continue to work.

When considering Windows Azure for your storage think about:

1. You should use only the parts of Windows Azure that you really need. If you need to store backup blob type of data – use only that. There is a good advantage to consider when you have applications to run that will use Windows Azure Storage. If you deploy your application to Windows Azure as well as the data to the same datacenter then the internal data transfer costs between this application and storage is without cost. If you instead run your apps on premise and store data in the cloud the transfer of data to and from the cloud carries a cost.
2. Regarding the cost you should really make a data storage estimate and analysis before you start up deploying. Your application should have a plan for the amount of data stored, transferred and the duration of storage. This is true on premise too, as discussed above, and data storage plans and budgets will become a more and more important part of any application for the future.
3. Windows Azure Storage means learning to use a new API. Perhaps not a dramatic thing but the three storage options also affects the way you build the rest of your application. If you disagree chances are you need to learn more about storing data in the cloud.

Links

Windows Azure SDK

Windows Azure Tools for Visual Studio

Cloud Storage Studio – a SSMS look alike for Windows Azure Storage

Fiddler2 – Web debugging proxy

CloudStorage.API @ CodePlex

Azure Contrib @ CodePlex

SQL Azure Migration Wizard

Downloads

Ziped version of the demo code in the Windows Azure Queue Storage sample:

AzureStorage

Slides from the presentation:

EffektivOchOandligLagringIMolnet.ppsx

EffektivOchOandligLagringIMolnet.pdf

Slides for the demo attached as a zip above

DemoWindowsAzureCloudQueue.ppsx

DemoWindowsAzureCloudQueue.pdf

Final Words

We would like to thank Microsoft for arranging TechDays, we had a blast! Thanks to the audience for listening.

Cheers,

Peter von Lochow @vonlochow and Magnus Mårtensson @noopman

First step is to boot an instance. You need the command line tools for this, as neither the AWS Management Web Console nor ElasticFox currently supports this right now (note to developers - please add!).

ec2-run-instances --region eu-west-1 \
     -K pk-YOURKEYHERE.pem \
     -C cert-YOURCERTHERE.pem \
     -b '/dev/sda1=:100' \
     ami-d7a78ca3 \
     -g my-security-group -g common-security-group \
     -t m1.large \
     -k thekeyhere \
     --disable-api-termination \
     --instance-initiated-shutdown-behavior stop \
     -z eu-west-1a

• The command is ec2-run-instances with an 's' in the end. There is another command in the API without the s, which doesn't work.
• -b is the most important flag here. It says to make the boot disk (/dev/sda is Linux speek for C:) 100 GB, despite what the AMI manifest says (which is 30 GB).
• ami-d7a78ca3 is the Windows image, in this case a 64bit Windows 2008.
• -g security-group you should add as many as you like. Remember to think these through, since you cannot change which groups an instance belongs to.
• The flags --disable-api-termination --instance-initiated-shutdown-behavior stop are really nice, because that make sure you cannot accidentally terminate the instance, making the harddrive disappear.
• Note that I'm running in the EU region here.

Ok, so now you have a running Windows server. Once it has booted, you log on using remote desktop (well, as soon as you have the generated password, which takes 15 min). PLease note that the C: drive will show up as 30 GB at this point. The partition is still only 30 GB, even if the virtual harddrive is 100 GB.

1. Go into the windows management console. Go to disk management.
2. Right-click on the C: drive. Choose Extend volume from the context menu.
3. In the wizard that pops up, just accept the defaults, and click finish.

Done! The change is instant (no reboot or anything), and your system drive C: is now 100 GB.

I found a simple solution to a very common problem. While profiling I found that remove in this little method took a lot of the time.

   public void MovePropertyFirst(IProperty property)
   {
      properties.Remove(property);
      properties.Insert(0, property);
   }

The reason was, that it's time consuming to compare the properties by equality, for complex types. I think that in most (?) cases we want to delete the very same instance we supply as parameter to the remove method.

So I implemented a ReferenceEquals based remove, and by that I cut the time spent in remove by about 72 times!

  public static bool RemoveFrom<T>(this IList<T> list, T itemToRemove)
  {
    if(list.Count == 0)
      return false;
    int index = 0;
    foreach (var item in list)
    {
      if (ReferenceEquals(item, itemToRemove))
      {
        list.RemoveAt(index);
        return true;
      }
      index++;
    }
    Debug.Assert(false, "Item to delete not found");
    //equality based fall back
    return list.Remove(itemToRemove);
  }