Archive for December, 2006

Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.


Have you ever got this kind of error when you are doing an Async postback using AJAX.NET (starting from Beta 2 if I’m not mistaken and going all the way to the current RC1 – at least at the time of writing this post) ?

It seems the newer versions of AJAX.NET really hates having “Response.Write” being called while doing an Async postback. It changes the response a bit causing it a hard time extracting the changed values and updating the changes using JavaScript on the client side.

If you get this error go through your page and all the controls in it (including controls within controls) and make sure you don’t have a “Response.Write” in the markup page.

Having “Response.Write” in the code behind in an event that is fired on an Async postback like Page_Load, Page_Render or the handler that handles that exact event can cause the same problem.

If you must use “Response.Write” you can get a similar solution by using a Label control and update it instead of using “Response.Write“.

If you use “Response.Write” in markup pages (ASPX or ASCX) replace them with either the “=” syntax (<% = MyProperty %>) or use the same solution mentioned above, adding a Label control and updating it in the code behind.

Maoni (which has a great blog that I’d recommend everyone to read) posted a set of posts (first, second and third – 3 so far…) about what the difference between performance data reported by different tools and what does it actually mean.

When you use a tool that collects performance data (or any data for that matter) you should always be aware of how this data is being collected and what does it say in the context of that tool.

Manoi does a fine job and describing numerous tools such as perfmon and WinDbg (with the use of the SOS extension).

See my previous post “Perfmon – Your debugging buddy” for some information about how various .NET counters can help you debug your application.

I’ve got a request from a reader, JasonL, to post the function I’ve written to overcome the query string problem that I’ve talked about in the previous post.

You can take a look at my solution here.

My implementation is to take the query part of the current URL, split it and only then perform URL decode on the values (only) of each parameter.

I know that some of you will probably implement the function’s prototype a bit differently by passing the URL to it instead of the function extracting the URL directly from the current request, but to make things simpler that the route I’ve chosen.

The main “problem” with my implementation is that I use a SortedDictionary (the generic one) which will not return null when a key does not exists, instead, it will throw an exception (so be sure to use the ContainsKey function).

I probably did that mainly from a lazy point of view and I just love generics 🙂

Anyhow, enjoy.

Sometimes its the little bugs that really get to you. They are so small that you spend quite a lot of time figuring out what’s wrong and then it hits you.

In my case, the problem was simple. I had a parameter being passed to me on the URL.
The URL looked something like this:

http://www.myapp.com/somepage.aspx?param1=text1%2c+text2%26text3&param2=true

param1 has a URL encoded value which translates into (without the double quotes):
text1, text2&text3

Yeap, it has a “&” character as the value, but its URL encoded so it suppose to be OK.

When I went to get the value of param1 by using:

var string a = Request.QueryString[“param1”];

The value I got was:

text1, text2

No text3 for some reason.

It seems that in certain cases there is a bug. I suspect that it URL decodes the query string before it cuts it up and fill in the Request.QueryString collection.
I didn’t fill like going through all the massive amounts of code of HttpRequest and friends using Reflector, so I just wrote a function that handles the URL decode and splitting issues correctly.

If you wish, I can post it as a link here.

I received a question today through my Yedda Ask Widget (that’s the nice little box on the right that you are more than welcome to use to ask me questions directly and have all the knowledge available on Yedda. Disclosure: Yedda is my day work 🙂 )

greenaj asked why the “-gen” parameter of the “!dumpheap” is missing from the SOS.dll that shipped with .NET Framework 2.0 (I’ve previously talked about the parameters that one can use with “!dumpheap” here, but its for the SOS that comes with WinDbg and is only good for .NET 1.1)

It seems that the SOS.dll that shipped in .NET 2.0 has, in some areas, less functionality than its sibling – SOS of .NET 1.1 – that is being updated regularly with every WinDbg version.

I did offer greenaj another way of doing that same thing without the “-gen” parameter.
It is based upon combining “!eeheap -gc” (which shows all the addresses of the various memory segments of each generation) and using the “start” and “end” command parameters of “!dumpheap“.

First, run “!eeheap -gc” and get the following output:
0:014> !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x013f694c
generation 1 starts at 0x013cb21c
generation 2 starts at 0x01391000
ephemeral segment allocation context: (0x01406de8, 0x01408970)
segment begin allocated size
001b2da0 7a721784 7a74248c 0x00020d08(134408)
00197dc8 7b451688 7b467f9c 0x00016914(92436)
001847b0 790d6358 790f5800 0x0001f4a8(128168)
01390000 01391000 01408970 0x00077970(489840)
Large object heap starts at 0x02391000
segment begin allocated size
02390000 02391000 0239a130 0x00009130(37168)
Total Size 0xd7564(882020)
——————————
GC Heap Size 0xd7564(882020)

The bold and underlined number, for example, shows that generation 2 start at the address of 01391000. At the list of segments below we can see that we have a segment who’s address starts at 01391000 and ends at 01408970.

Now we can run the command “!dumpheap 01391000 01408970” and see all the objects in this segments which are, in fact, all generation 2 objects (at least in this sample application).

I just hope newer versions of SOS for .NET 2.0 will be released more frequently with newer version of WinDbg, like they did with the SOS for .NET 1.1.