So in a code-base I was working in yesterday, we use PInvoke to call out to the Performance Data Helper (PDH) API’s to collect performance information for machines without using Perfmon.  One of those PInvoke calls looked like this:

/*

PDH_STATUS PdhExpandCounterPath(

LPCTSTR szWildCardPath,

LPTSTR mszExpandedPathList,

LPDWORD pcchPathListLength

);

*/

[DllImport("pdh.dll", CharSet = CharSet.Unicode)]

private static extern PdhStatus PdhExpandCounterPath(

string szWildCardPath,

[MarshalAs(UnmanagedType.LPArray, SizeParamIndex = 3)] char[] mszExpandedPathList,

ref uint pcchPathListLength

);

In .NET 3.5 and below, this PInvoke call works perfectly fine.  In .NET 4.0, though, I saw this exception:

System.Runtime.InteropServices.MarshalDirectiveException: 


Cannot marshal 'parameter #2': Array size control parameter index is out of range. 


at System.Runtime.InteropServices.Marshal.InternalPrelink(IRuntimeMethodInfo m) 


at System.Runtime.InteropServices.Marshal.Prelink(MethodInfo m)

So, can you identify what’s wrong in the code above?

Well, the Array size control parameter index indicates the zero-based parameter that contains the count of the array elements, similar to size_is in COM.  Because the marshaler cannot determine the size of an unmanaged array, you have to pass it in as a separate parameter.  So in the call above, parameter #2, we specify “SizeParamIndex = 3” to reference the pcchPathListLength parameter to set the length of the array.  So what’s the catch?

Well, since the SizeParamIndex is a zero-based index, the 3rd parameter doesn’t really exist.  So, to fix this, we just change the “SizeParamIndex=3” to “SizeParamIndex=2” to reference the pcchPathListLength:

/*

PDH_STATUS PdhExpandCounterPath(

LPCTSTR szWildCardPath,

LPTSTR mszExpandedPathList,

LPDWORD pcchPathListLength

);

*/

[DllImport("pdh.dll", CharSet = CharSet.Unicode)]

private static extern PdhStatus PdhExpandCounterPath(

string szWildCardPath,

[MarshalAs(UnmanagedType.LPArray, SizeParamIndex = 2)] char[] mszExpandedPathList,

ref uint pcchPathListLength

);

It looks like in .NET 3.5 and below, though, we allowed you to reference either 1-based index or a zero-based index but in .NET 4.0, we buttoned that up a bit and force you to use the zero-based index.    Big thanks to my co-worker and frequent collaborator, Zach Kramer for his assistance in looking at this issue.

Until Next Time!

So, many apologies for dropping off the face of the blogosphere lately.  Fortunately (or unfortunately, depending on your perspective), I’ve been really busy at work.  I’ve been working on some really cool things that I hope I’ll be able to talk about publicly soon.  For now, though, I wanted to pass on something that I haven’t seen documented in other places that actually helped me quite a bit lately. 

So, for those of you that generate Word documents via the OpenXML (or any other of a variety of methods), you may have come across something like this when you opened up a document you just generated:

There are some problems with this message but the big one is that it just says “Line: 1, Column: 0”.  Not exactly a map to the error.  As a result, you may have stared at this message for a long time and wondered – “how the heck do I fix this?  What is the real problem?”.  Well, let me show you a really quick and easy way of getting more information than what is initially provided.

Step 1:  Change the extension from docx to zip

As you may or may not know, all OpenXML documents (or Office documents since Office 2007) are actually zip files at their core. That means you can just crack them open and peer inside.

See the difference?  Easy!

Step 2:  Extract the zip file to a folder

Once again, pretty straight forward.  Once you extract the zip file above, you should see a structure like the following:

Now, from here – you’ll be able to locate the file referenced in that cryptic error message above. 

Step 3:  Find the file that’s causing the problem

In the example above, the message states that the problem lies with the file “/word/document.xml” so just navigate to the “word” folder and find the “document.xml”.

Step 4:  Open and format the file in Visual Studio

One of the great features of Visual Studio is that it can format an XML file for you.  So, in our case, the document.xml file is natively just one big line:

Incidentally, this is why the message always states “Line 1,…” in the error message.  As far as Word is concerned, the problem IS on the first line.  Fortunately for us, though, Word can take that single line file and format it for us.  Just use the Edit > Advanced > Format Document option in Visual Studio:

That will then format the XML and make it look closer to:

Step 5:  Recreate the Word doc and get the additional information

Now that you have the file formatted appropriately, you can just re-create the Word document and re-open it.  For this, just go back to the root of the document, select all the files/folders and then zip it back up:

Once it’s zipped back up again, just change the extension from zip to docx and re-open the file.  When you do so, you’ll see the following:

Note that now, you’ll see that it says “Line: 5667, Column: 0” – which will point to the exact line causing the problem – which allows you to just go back to the “document.xml” file you already have open in Visual Studio to see the problem.  In our case:

Note that this won’t magically fix your problem.  You’ll still need to examine the WordML to figure out the problem – but at least you know where to go.  And knowing is half the battle! 

That’s all for now and I will be back with some more developer stuff soon. 

Until next time!

Read a great blog entry by Scott Hanselman recently talking about the parallel dilemma that I’m sure we’ll see folks face in the future with the (old/new) Parallel classes.  I wanted to add a few things to this discussion as he focused on the mechanics of the parallel requests but maybe not the potential effects it could have on the macro view of your application.  This was originally written as an e-mail I sent to my team but thought others might find it interesting.

There will be an inclination by people to use the new Parallel functionality in .NET 4.0 to easily spawn operations onto numerous background threads.  That will generally be okay for console/winform/wpf apps – but could also be potentially bad for ASP.NET apps as the spawned threads could take away from the processing power and threads available to process new webpage requests.  I’ll explain more on that later. 

For example, by default, when you do something like Parallel.ForEach(…) or some such, the parallel library starts firing Tasks to the thread pool so that it can best utilize the processing power available on your machine (oversimplification but you get the idea).  The downside is that the thread pool contains a finite number of worker threads threads available to a process.  Granted, you have about 100 threads per logical processor in .NET 4 – but it’s worth noting.

While Scott’s entry talks about the new way to implement the Async pattern, I’ve already seen a bunch of folks use the “Parallel” class because it abstracts away some of the plumbing of the Async operations and that ease of use could become problematic. 

For example, consider this code:

string[] myStrings = { "hello", "world", "you", "crazy", "pfes", "out", "there" };


Parallel.ForEach(myStrings, myString =>

{


System.Console.WriteLine(DateTime.Now + ":" + myString + 


" - From Thread #" + 


Thread.CurrentThread.ManagedThreadId);

Thread.Sleep(new Random().Next(1000, 5000));


});

This is a very simple implementation of Parallel’izing a foreach that just writes some string output with an artificial delay.  Output would be something like:

11/16/2010 2:40:05 AM:hello - From Thread #10
11/16/2010 2:40:05 AM:crazy - From Thread #11
11/16/2010 2:40:05 AM:there - From Thread #12
11/16/2010 2:40:06 AM:world - From Thread #13
11/16/2010 2:40:06 AM:pfes - From Thread #14
11/16/2010 2:40:06 AM:you - From Thread #12
11/16/2010 2:40:07 AM:out - From Thread #11 

Note the multiple thread ids and extrapolate that out to a server that has more than just my paltry 2 CPUs.  This can be potentially problematic for ASP.NET applications as you have a finite number of worker threads available in your worker process and they must be shared across not just one user but hundreds (or even thousands).  So, we might see that spawning an operation across tons of threads can potentially reduce the scalability of your site.

Fortunately, there is a ParallelOptions class where you can set the degree of parallel’ism.  Updated code as follows:

string[] myStrings = { "hello", "world", "you", "crazy", "pfes", "out", "there" };


ParallelOptions options = new ParallelOptions();

options.MaxDegreeOfParallelism = 1;


Parallel.ForEach(myStrings,options, myString =>

{


// Nothing changes here

...


});

This would then output something like:

11/16/2010 2:40:11 AM:hello - From Thread #10
11/16/2010 2:40:12 AM:world - From Thread #10
11/16/2010 2:40:16 AM:you - From Thread #10
11/16/2010 2:40:20 AM:crazy - From Thread #10
11/16/2010 2:40:23 AM:pfes - From Thread #10
11/16/2010 2:40:26 AM:out - From Thread #10
11/16/2010 2:40:29 AM:there - From Thread #10

Since I set the MaxDegreeOfParallelism to “1”, we see that it just uses the same thread over and over.  Within reason, that setting *should* correspond to the number of threads it will use to handle the request. 

Applying to a website

So, let’s apply the code from the above to a simple website and compare the difference between the full parallel implementation and the non-parallel implementation.  The test I used ran for 10 minutes with a consistent load of 20 users on a dual-core machine running IIS 7.

In all of the images below, the blue line (or baseline) represents the single-threaded implementation and the purple line (or compared) represents the parallel implementation . 

We’ll start with the request execution time.  As we’d expect, the time to complete the request decreases significantly with the parallel implementation.

But what is the cost from a thread perspective?  For that, we’ll look at the number of physical threads:

As we’d also expect, there is a significant increase in the number of threads used in the process.  We go from ~20 threads in the process to a peak of almost 200 threads throughout the test.  Seeing as this was run on a dual-core machine, we’ll have a maximum of 200 worker threads available in the thread pool.  After those threads become depleted, you often see requests start getting queued, waiting for a thread to become available.  So, what happened in our simple test?  We’re look at the requests queued value for that:

We did, in-fact, start to see a small number of requests become queued throughout our test.  This indicates that some requests started to pile up waiting for an available thread to become available. 

Please note that I’m NOT saying that you should not use Parallel operations in your website.  You saw in the first image that the actual request execution time decreased significantly from the non-parallel implementation to the parallel implementation. But it’s important to note that nothing is free and while parallelizing your work can and will improve the performance of a single request, it should also be weighed against the potential performance of your site overall.

Until next time.

“We shall neither fail nor falter; we shall not weaken or tire…give us the tools and we will finish the job.” – Winston Churchill

I don’t often blog about specific language features but over the past few weeks I’ve spoken to a few folks that did not know of the “yield” keyword and the “yield return” and “yield break” statements, so I thought it might be a good opportunity to shed some light on this little known but extremely useful C# feature.  Chances are, you’ve probably indirectly used this feature before and just never known it.

We’ll start with the problem I’ve seen that plagues many applications.  Often times, you’ll call a method that returns a List<T> or some other concrete collection.  The method probably looks something like this:

public static List<string> GenerateMyList()

{

List<string> myList = new List<string>();


for (int i = 0; i < 100; i++)

{


myList.Add(i.ToString()); 



}


return myList;


}

I’m sure your logic is going to be significantly more complex than what I have above but you get the idea.  There are a few problems and inefficiencies with this method.  Can you spot them?

• The entire List<T> must be stored in memory.
• Its caller must wait for the List<T> to be returned before it can process anything.
• The method itself returns a List<T> back to its caller.

As an aside – with public methods, you should strive to not return a List<T> in your methods.  Full details can be found here .  The main idea here is that if you choose to change the method signature and return a different collection type in the future, this would be considered a breaking change to your callers.

In any case, I’ll focus on the first two items in the list above.  If the List<T> that is returned from the GenerateMyList() method is large then that will be a lot of data that must be kept around in memory.  In addition, if it takes a long time to generate the list, your caller is stuck until you’ve completely finished your processing.

Instead, you can use that nifty “yield” keyword.  This allows the GenerateMyList() method to return items to its caller as they are being processed.  This means that you no longer need to keep the entire list in memory and can just return one item at a time until you get to the end of your returned items.  To illustrate my point, I’ll refactor the above method into the following:

private static IEnumerable<string> GenerateMyList()

{

for (int i = 0; i < 100; i++)

{

string value = i.ToString();

Console.WriteLine("Returning {0} to caller.", value);

yield return value;

}


Console.WriteLine("Method done!");


yield break;

}

A few things to note in this method.  The return type has been changed to an IEnumerable<string>.  This is one of those nifty interfaces that exposes an enumerator.  This allows its caller to cycle through the results in a foreach or while loop.  In addition, the “yield return i.ToString()” will return that item to its caller at that point and not when the entire method has completed its processing.  This allows for a very exciting caller-callee type relationship.  For example, if I call this method like so:

IEnumerable<string> myList = GenerateMyList();


foreach (string listItem in myList)

{

Console.WriteLine("Item: " + listItem);

}

The output would be:

Thus showing that each item gets returned at the time we processed it.  So, how does this work?  Well, at compile time, we will generate a class to implement the behavior in the iterator.  Essentially, this means that the GenerateMyList() method body gets placed into the MoveNext() method.  In-fact, if you open up the compiled assembly in Reflector, you see that plumbing in place (comments are mine and some code was omitted for clarity’s sake):

private bool MoveNext()

{


this.<>1__state = -1;

this.<i>5__1 = 0;

// My for loop has changed to a while loop.

while (this.<i>5__1 < 100)

{

// Sets a local value

this.<value>5__2 = this.<i>5__1.ToString();

// Here is my Console.WriteLine(...)

Console.WriteLine("Returning {0} to caller.", this.<value>5__2);

// Here is where the current member variable

// gets stored.

this.<>2__current = this.<value>5__2;

this.<>1__state = 1;

// We return "true" to the caller so it knows

// there is another record to be processed.

return true;

...

}

// Here is my Console.WriteLine() at the bottom

// when we've finished processing the loop.

Console.WriteLine("Method done!");

break;



}

Pretty straightforward.  Of course, the real power is that it the compiler converts the “yield return <blah>” into a nice clean enumerator with a MoveNext().  In-fact, if you’ve used LINQ, you’ve probably used this feature without even knowing it.  Consider the following code:

private static void OutputLinqToXmlQuery()

{

XDocument doc = XDocument.Parse

(@"<root><data>hello world</data><data>goodbye world</data></root>");


var results = from data in doc.Descendants("data")

select data;


foreach (var result in results)

{

Console.WriteLine(result); 


}

}

The “results” object, by default will be of type “WhereSelectEnumerableIterator” which exposes a MoveNext() method.  In-fact, that is also why the results object doesn’t allow you to do something like this:

var results = from data in doc.Descendants("data")

select data;


var bad = results[1];

The IEnumerator does not expose an indexer allowing you to go straight to a particular element in the collection because the full collection hasn’t been generated yet.  Instead, you would do something like this:

var results = from data in doc.Descendants("data")

select data; 



var good = results.ElementAt(1);

And then under the covers, the ElementAt(int) method will just keep calling MoveNext() until it reaches the index you specified.  Something like this:

Note:  this is my own code and is NOT from the .NET Framework – it is merely meant to illustrate a point.

public static XElement MyElementAt(this IEnumerable<XElement> elements, 


int index)

{

int counter = 0;

using (IEnumerator<XElement> enumerator = 


elements.GetEnumerator())

{ 


while(enumerator.MoveNext()){

if (counter == index)

return enumerator.Current;

counter++;

}

}


return null;

}

Hope this helps to demystify some things and put another tool in your toolbox.

Until next time.

In my previous post, I added to my series of entries on making sense of your ASP.NET event log error messages.  Note that this is entry #4 in this series.  The previous three entries can be found here:

• Part 1:  Parsing ASP.NET event log error messages for fun and profit
• Part 2:  Don’t guess when it comes to performance…
• Part 3:  Pivoting your ASP.NET event log error messages

In that last post, I walked through the PAuthorLib.dll and showed you how to crawl through your event log error messages and create a pivot collection.  The result of that initial effort was a nice view into our events:

While this certainly got the job done and is a very powerful and compelling view into our data, we need to realize that as our data grow, the amount of entries in our linked collection is limited.  From the Developer Overview, we see that the maximum number of items we should have in a single collection is 3,000:

So, while a simple collection will get the job done for your smaller amounts of data, you will really run into some challenges with your larger datasets like our ASP.NET event log error messages.  To combat this limitation you can create what’s called a Linked Collection.  The idea is that it’s just a way for you to link together related collections in order to provide a seamless experience for your users.  In our case, a natural break for our collections will be based upon the exception type with a summary collection and then a separate collection for each exception type.  If I were to draw this out: 

Event Log Header Collection Source

The idea behind this structure is that the Exception summary would simply link to each of these exception collections.  First, we’ll create a colleciton source for our exception summary.  As in our previous collection source (in my last blog post), we inherit from the AbstractCollectionSource class and use the LoadHeaderData() method to add our facet categories to the collection.  In this case, we’ll create two categories – the number of Occurrences and the Urls where the exception occurred.  Another difference is that we are going to pass the already parsed collection of messages into the constructor.  The reason for that is so we don’t have to repeat the parsing of the event log messages multiple times.

class EventLogHeaderCollectionSource : AbstractCollectionSource

{


private IEnumerable<EventLogMessage> m_messages = null;


public EventLogHeaderCollectionSource(IEnumerable<EventLogMessage> messages, 


string inputFile)

: base(inputFile)

{


m_messages = messages;



}


#region Facets


private const string OCCURRENCES = "Occurrences";

private const string URLS = "Urls";


#endregion


protected override void LoadHeaderData()

{

this.CachedCollectionData.FacetCategories.

Add(new PivotFacetCategory(OCCURRENCES, PivotFacetType.Number));

this.CachedCollectionData.FacetCategories.

Add(new PivotFacetCategory(URLS, PivotFacetType.String));


this.CachedCollectionData.Name = 


"ASP.NET Error Messages - Summary";

this.CachedCollectionData.Copyright = 


new PivotLink("Source", "http://www.samuraiprogrammer.com");


}

}

Then, in the LoadItems() method, we provide the logic to generate the PivotItem collection.  The one key item to make note of is the use of the Href property of the PivotItem object.  This is where we specify the collection we wish to link to this item.  Since each of the PivotItems will be a summary of the number of each exception type – we’ll name the sub-collections by its exception type.  For example, NullReferenceException.cxml, SqlException.cxml, etc.

protected override IEnumerable<PivotItem> LoadItems()

{

var results = from log in m_messages

group log by log.Exceptiontype into l

orderby l.Count() descending, l.Key

select new

{

ExceptionType = l.Key,

ExceptionCount = l.Count()

};



int index = 0;

foreach (var result in results)

{

PivotItem item = new PivotItem(index.ToString(), this); 


item.Name = result.ExceptionType;

item.Description = "# of Exceptions: " + result.ExceptionCount.ToString();

item.AddFacetValues(OCCURRENCES, result.ExceptionCount);

item.Href = result.ExceptionType + ".cxml";


... 



index++;

yield return item;

}


yield break;

}

Event Log Collection Source Redux

Previously, when we generated the pivot collections, we were outputting all of the records into a single collection.  Now that we are generating a collection for each exception type, we will need to put a filter in our exception collection and then incorporate that filter into our item generation.  Other than that, the code we wrote previously remains largely unchanged, so I left the majority of it out and only included the snippets that we care about below.

class EventLogCollectionSource : AbstractCollectionSource

{

private IEnumerable<EventLogMessage> m_messages = null;

private string m_exceptionType = string.Empty;


public EventLogCollectionSource(

IEnumerable<EventLogMessage> messages, 


string exceptionType, 


string path)

: base(path)

{

m_messages = messages;

m_exceptionType = exceptionType;

}


protected override void LoadHeaderData()

{

...

this.CachedCollectionData.Name = 


string.Format("{0} Error Messages", m_exceptionType);

...

}


protected override IEnumerable<PivotItem> LoadItems()

{

var results = (from message in m_messages

where message.Exceptiontype == m_exceptionType

select message);


int index = 0;

foreach (EventLogMessage message in results)

{

PivotItem item = 


new PivotItem(index.ToString(), this);

item.Name = message.Exceptiontype;

item.Description = message.Exceptionmessage;


...


index++;

yield return item;

}

yield break;

}

}

Generate and test the collection

Then, the only thing we have left to do is generate and test our linked collections.  I won’t go into a lengthy explanation of how we generate the collections because I did that in the last blog entry.  I will show the broad strokes required to tie this all together, though:

// Load the raw messages into a collection

IEnumerable<EventLogMessage> messages = 


LoadEventLogMessages(inputFile).ToList();


// Generate summary pivot collection

EventLogHeaderCollectionSource sourceSummary = 


new EventLogHeaderCollectionSource(messages, inputFile);

...

summaryTargetFilter1.Write(sourceSummaryFilter1);


// Get the aggregate results so we know the filters

// for our exception pivot collections

var summaryResults = from log in messages

group log by log.Exceptiontype into l

orderby l.Count() descending, l.Key

select new

{

ExceptionType = l.Key,

ExceptionCount = l.Count()

};


foreach (var resultItem in summaryResults)

{

// Generate pivots for each exception type

EventLogCollectionSource source = 


new EventLogCollectionSource(messages, 


resultItem.ExceptionType, 


inputFile);

...

targetFilter1.Write(sourceFilter1);

}

Once we we have this code and everything has been generated, if we open the output folder, we’ll see the following structure:

We see our ExceptionSummary pivot collection and all of the deep zoom folders.  So, when we open the Pivot tool, we’ll see a nice parent collection:

This gives us a nice breakdown of the number of occurrences for each exception in our source data.  Immediately we see an outlier (more on that later) between the 6,000 and 7,000 item mark and when we select that tile, we see the following:

We also see a green “Open” box (surrounded in a red rectangle, my emphasis) which links to our NullReferenceException.cxml.  When we click that box, the tool will immediately open that collection in the UI for our perusal – providing a very similar look to what we saw in the last entry:

Closing Thoughts

Now, you may have noticed a contradiction above.  I said that a collection should have no more than 3,000 items and yet, with the NullReferenceException collection, we saw in the summary that it had over 6,000 items.  That is a very good point and will be a subject of a future blog post.  I wanted to illustrate the simple collections and the linked collections before we got into that third type of collection from above – the Dynamic Collection.  Stay tuned!