Blog posts by Kristoffer Sjöberg

Blog posts by Kristoffer Sjöberg2016-04-20T14:34:58.0000000Zhttps://world.optimizely.com/blogs/Kristoffer-Sjoberg/ Optimizely World A Burst Cache implementation releasedThere are few things more rewarding in site performance than enabling the Output Cache. This will store the ready-generated HTML to be served without executing any WebForms pages or Controller actions and their respective Views for MVC sites. In Episerver, the output cache is enabled in the applicationSettings element’s httpCacheExpiration attribute in web.config. That sets the … <a href="http://blog.q1.se/2016/04/20/a-burst-cache-implementation-released/" class="more-link">Continue reading "A Burst Cache implementation released"</a>2016-04-20T14:34:58.0000000Z

Blog post

Methods of .NET self-annihilation part 4: Background Thread ExceptionsDeath by Background Thread Exception (including ThreadPool User Work Items) If you use a thread or ThreadPool.QueueUserWorkItem to run code asynchronously and don’t catch your exceptions inside your WaitCallback, you will bring your entire application down when it breaks. [crayon-580f8f3d3ab8d685111634/] On the highlighted line, a NullReferenceException is thrown (because a background thread has no HttpContext). If you … <a href="http://blog.q1.se/2016/03/18/methods-of-net-self-annihilation-part-4-background-thread-exceptions/" class="more-link">Continue reading "Methods of .NET self-annihilation part 4: Background Thread Exceptions"</a>2016-03-18T11:49:32.0000000Z

Blog post

Methods of .NET self-annihilation part 3: Stack OverflowThis is another issue that results in Frequent Web Application Restarts, which causes the performance to plunge. Death by Stack Overflow This one is interesting, yet it has nothing to do with StackOverflow.com. The StackOverflowException is one of very few exception classes in .NET that are not catch-able. Scratch that, it’s not possible to “swallow” it in a … <a href="http://blog.q1.se/2016/03/17/methods-of-net-self-annihilation-part-3-stack-overflow/" class="more-link">Continue reading "Methods of .NET self-annihilation part 3: Stack Overflow"</a>2016-03-17T14:05:24.0000000Z

Blog post

Memory Leak in CMS prior to 9.0.2This bug appears only in load-balanced / remote events setups for CMS versions between 7.5 and 9.0.2 (released September 14th 2015, in which it was fixed). It’s reported as bug CMS-1405. This memory leak is relatively slow. Because of the way that ASP.NET handles cache, the application’s memory allocation will remain constant while the cache portion … <a href="http://blog.q1.se/2016/03/14/memory-leak-in-cms-prior-to-9-0-2/" class="more-link">Continue reading "Memory Leak in CMS prior to 9.0.2"</a>2016-03-14T16:25:24.0000000Z

Blog post

Methods of .NET self-annihilation part 2: IIS pingLast post I discussed why Frequent Web Application restarts are bad. This is an issue that can cause you pain trying to get the application back up running again: Death by IIS Ping IIS’ built-in health monitoring is quite simple, but despite it having the word “ping” in its name, it has nothing to do with … <a href="http://blog.q1.se/2016/03/14/methods-of-net-self-annihilation-part-2-iis-ping/" class="more-link">Continue reading "Methods of .NET self-annihilation part 2: IIS ping"</a>2016-03-14T07:20:32.0000000Z

Blog post

Methods of .NET self-annihilation part 1: Frequent Web Application RestartsThere are many different ways you may inadvertently kill your web application’s presence online. Here I try to list the major reasons an IIS site running .NET may underperform. The trickiest cases to prevent are the time bombs. That code that runs really well in development, but starts misbehaving when put in production. Not immediately of course, but … <a href="http://blog.q1.se/2016/03/11/methods-of-net-self-annihilation-part-1-frequent-web-application-restarts/" class="more-link">Continue reading "Methods of .NET self-annihilation part 1: Frequent Web Application Restarts"</a>2016-03-11T09:39:33.0000000Z

Blog post

Commerce: Failed to migrate property decimal: Timeout expired.Today I was involved in an issue running the upgrade migration steps in Episerver Commerce. This step is performed if you upgrade past Episerver Commerce 9.5.0 that came with update 94. [crayon-580f8f3d3d3ad338705338/] How disappointing! Even though care has been taken in the migration step to do it in small units and with an extended SQL timeout of … <a href="http://blog.q1.se/2016/03/10/commerce-failed-to-migrate-property-decimal-timeout-expired/" class="more-link">Continue reading "Commerce: Failed to migrate property decimal: Timeout expired."</a>2016-03-10T14:21:25.0000000Z

Blog post

PageTypeBuilder doesn’t cacheThis is a PageTypeBuilder specific post, so it does not apply to users of CMS 7+. This post balances yesterday’s post which discusses the effects of caching. This one discusses the effects of not caching. Consider the following code example: [crayon-580f8f3d3df63283616809/] See the class variable [crayon-580f8f3d3df6d496635177-i/]? The variable that stores the value retrieved from the first non-null property … <a href="http://blog.q1.se/2016/03/09/pagetypebuilder-doesnt-cache/" class="more-link">Continue reading "PageTypeBuilder doesn’t cache"</a>2016-03-09T08:00:08.0000000Z

Blog post

Rule of thumb: Never have [Ignore] properties in a ContentType/modelThis applies to WebForms and MVC scenarios alike, but it’s mostly MVC users that are tempted in doing it: Never put request specific data into the ContentType model class! It may sound obvious to some, and not so obvious to others. Regardless, it’s an easy mistake to make. Worse is, doing it may survive development, … <a href="http://blog.q1.se/2016/03/08/rule-of-thumb-never-have-ignore-properties-in-a-contenttypemodel/" class="more-link">Continue reading "Rule of thumb: Never have [Ignore] properties in a ContentType/model"</a>2016-03-08T08:00:21.0000000Z

Blog post

Find _config requestsThe French say “jamais deux sans trois”. If something happens twice, it will happen again. Twice I have seen questions about why Episerver Find performs multiple/repeated requests to the Find index for its configuration (_config) when working to minimize the number of queries. Sometimes these requests are spotted when using a Performance Profiler such as the excellent one … <a href="http://blog.q1.se/2016/03/07/find-_config-requests/" class="more-link">Continue reading "Find _config requests"</a>2016-03-07T10:00:31.0000000Z

Blog post

.NET 4 Linq Expression Lock ConvoyA few months ago, I was involved in a performance case involving an old CMS6R2 site. They explained that the site seemed to go down for a couple of minutes, to then automatically recover. During the downtime, any browser connecting to the site would be spinning at “Waiting for reply…” and this could potentially go on … <a href="http://blog.q1.se/2016/03/04/net-4-linq-expression-lock-convoy/" class="more-link">Continue reading ".NET 4 Linq Expression Lock Convoy"</a>2016-03-04T09:22:34.0000000Z

Blog post

The Large Object Heap and why you should know about itTo write an application, you don’t have to know very much about how .NET manages memory. To write an application that performs, it will be crucial. In this post I will focus on the memory management / Garbage Collection aspects of a .NET application. Too many times when I have been thrown into a performance troubleshooting case, I have … <a href="http://blog.q1.se/2016/03/02/the-large-object-heap-and-why-you-should-know-about-it/" class="more-link">Continue reading "The Large Object Heap and why you should know about it"</a>2016-03-02T15:46:29.0000000Z

Blog post

Castle.Core lock contention issueA while back, a customer reported that their site’s performance was very “stop and go”. Suddenly, it would just stop delivering web pages. Neither the database, web servers nor any other infrastructure components seemed to be experiencing any stress. I asked them to use my colleague Mattias Lövström’s excellent StackDump tool when the site was … <a href="http://blog.q1.se/2016/03/01/castle-core-lock-contention-issue/" class="more-link">Continue reading "Castle.Core lock contention issue"</a>2016-03-01T10:09:57.0000000Z

Blog post

Troubleshooting a problem with POST-requests in an environment with mixed NTLM and Forms authenticationIn most Intranet solutions there’s a desire to make the users of the Intranet be able to use the Intranet without logging in. This can be done in many ways, but this blog post takes one particular solution and takes a closer look at it. The partner had created a special FormsAuthentication module to replace the standard ASP.NET <a href="http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationmodule.aspx" target="_blank">FormsAuthentication module</a>. Using some reflection it piggybacked on the OnEnter and OnLeave private method implementations in that module to copy the normal FormsAuthentication behavior that redirects the user to a login page if the <a href="http://msdn.microsoft.com/en-us/library/system.web.security.formsauthenticationticket(v=vs.110).aspx" target="_blank">authentication ticket</a> is not among the user’s cookies. As a part of the setup of this module, two virtual paths had been created whose requests were captured by a special module. One of those paths was reconfigured using a <a href="http://msdn.microsoft.com/en-us/library/b6x6shw7(v=vs.100).aspx" target="_blank">web.config location element</a> to add a <a href="http://msdn.microsoft.com/en-us/library/532aee0e(v=vs.100).aspx" target="_blank">authentication element</a> that specified that that path expects the user to authenticate using <a href="http://msdn.microsoft.com/en-us/library/aa720716(v=vs.71).aspx" target="_blank">Windows authentication</a>. The two paths were /WindowsLogin (configured with Windows authentication) and /Authenticate (configured using Forms authentication). When the user was decided to be unauthenticated, the normal behavior of the Forms authentication module is to redirect the user to the login page. In this case it was configured to be /WindowsLogin (see <a href="http://msdn.microsoft.com/en-us/library/1d3t3c61(v=vs.100).aspx" target="_blank">loginUrl in the documentation</a>). When that Url was successfully executed, the server side code would issue a forms authentication ticket with the credentials the user (or web browser) supplied. In the Intranet zone, Internet Explorer attempts an NTLM/Negotiate based authentication automatically, so no login is required. On failure, the normal forms authentication screen would present via a redirect to /Authenticate. The solution mostly worked, but there were some problems in critical areas of the web site. Notably, postback-requests would occasionally render as non-postbacks. This is particularly bad when that postback contain information the user has spent much time creating. Typical case would be the user creating a new page or editing an existing page. After about one minute from the moment the page was downloaded, the save action would simply reload the page. After some troubleshooting we concluded that the problem occurred because Internet Explorer believed that all pages on the intranet was protected with NTLM/Negotiate. It basically means that at each new connection made, the client is required to authenticate itself. HTTP Keep-alives allows a web browser to establish a single connection and then reuse it until the connection is closed. The idle timeout of keep alives in this environment was one minute. It is done by a (simplified below) four step process: <ol> <li>The browser sends a request for the protected resource, eg / episerver. </li> <li>The server responds 401 Unauthorized and provides a "NTLM challenge" to the browser. </li> <li>The browser computes a response to the server's given challenge and sends the response along with a new request for the protected resource. </li> <li>The server answers confirms the answer to the authentication and if it went well the server responds with 200 OK and process requests in full. </li> </ol> In step 1, the browser omits to send the POST data (the data entered in form fields on the page), as it is certain that the server will reply "401 Unauthenticated" and ignore the POST data so it would be pointless to send it. In step 3, the browser includes the POST data. Since the server and the browser has different ideas of what resources are protected with NTLM/Negotiate, this creates a conflict. The browser a expects a 401 response to resources protected by NTLM where the connection is not yet authenticated, but the server satisfies itself with the Forms Authentication ticket in the set of cookies sent by the client. This allows the server to act on a POST request without receiving the POST data (as it is omitted in step 1 of NTLM authentication), and then we will get the effect we saw - the "reloaded page" with emptied of form data. The solution was to add the NTLM / Negotiate protected resources in a virtual directory, eg /AuthenticationSubSystem/WindowsLogin, so that the browser think it's just the resources in that directory that requires NTLM/Negotiate authentication. The other resources are handled by the browser as usual. Previously the NTLM protected resources resided directly in the root which made the browser assume that other resources under the root and its subdirectories are protected with NTLM.2014-07-17T16:56:58.0000000Z

Blog post

Using ADPlus to create dumps on a specific .NET exceptionSometimes an application throws an exception and you need to have a look at the environment to be able to find the cause of the exception. To do this, it is convenient if it would be possible to capture a snapshot of the process precisely at the point when the exception is thrown. The example at hand is an issue where a customer reported that the application threw an <a href="http://msdn.microsoft.com/en-us/library/system.argumentexception.aspx" target="_blank">ArgumentException</a>: <code>ArgumentException: '', hexadecimal value 0x1B, is an invalid character.]    System.Xml.XmlEncodedRawTextWriter.InvalidXmlChar(Int32 ch, Char* pDst, Boolean entitize) +1702938    System.Xml.XmlEncodedRawTextWriter.WriteElementTextBlock(Char* pSrc, Char* pSrcEnd) +493    System.Xml.XmlEncodedRawTextWriter.WriteString(String text) +88    System.Xml.XmlWellFormedWriter.WriteString(String text) +87    System.Xml.XmlWrappedWriter.WriteString(String text) +15    System.ServiceModel.Syndication.TextSyndicationContent.WriteContentsTo(XmlWriter writer) +62    System.ServiceModel.Syndication.SyndicationContent.WriteTo(XmlWriter writer, String outerElementName, String outerElementNamespace) +430    System.ServiceModel.Syndication.Atom10FeedFormatter.WriteItemContents(XmlWriter dictWriter, SyndicationItem item, Uri feedBaseUri) +840    System.ServiceModel.Syndication.Atom10ItemFormatter.WriteItem(XmlWriter writer) +42    System.ServiceModel.Syndication.Atom10ItemFormatter.WriteTo(XmlWriter writer) +58    EPiServer.Search.IndexItemBase.ToSyndicationItemXml() +4104    EPiServer.Search.IndexRequestItem.ToSyndicationItemXml() +139    EPiServer.Search.Data.SearchFactory.AddToQueue(IndexRequestItem item, String namedIndexingService) +117    EPiServer.Search.SearchHandler.UpdateIndex(IndexRequestItem item, String namedIndexingService) +70    EPiServer.Community.Search.SearchHandler.UpdateIndex(Int32 entityId, IEntity entity, IndexAction action) +312    EPiServer.Community.Search.SearchHandler.AddEntitiesToIndex(GetCollection getCollection, Boolean overwrite) +233    EPiServer.Community.Search.SearchHandler.AddCommunityEntitiesToIndex(Type type, Boolean overwrite) +1536    EPiServer.Community.Search.SearchHandler.AddCommunityEntitiesToIndex(Boolean overwrite) +20</code> Interpreting the exception, we know that the problem occurs during the indexing of some community entity. However, the stack trace leaves us no hint of which entity, nor the field that contain the 0x1B character that the XML writer class is unable to handle. Again, <a href="http://msdn.microsoft.com/en-us/windows/hardware/gg463009" target="_blank">Debugging Tools for Windows</a> comes to the rescue. This time, I'll show you how to use <a href="http://msdn.microsoft.com/en-us/library/ff537953.aspx" target="_blank">ADPlus</a> to attach to a process and perform a dump each time an <a href="http://msdn.microsoft.com/en-us/library/system.argumentexception.aspx" target="_blank">ArgumentException</a> is thrown. Create a file, let's call it "dump-on-argumentexception.cfg", with the following content: <pre style="border-bottom: #cecece 1px solid; border-left: #cecece 1px solid; padding-bottom: 5px; background-color: #fbfbfb; min-height: 40px; padding-left: 5px; width: 100%; padding-right: 5px; overflow: auto; border-top: #cecece 1px solid; border-right: #cecece 1px solid; padding-top: 5px"><pre style="background-color: #fbfbfb; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"><ADPlus> </pre><pre style="background-color: #ffffff; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px">  </pre><pre style="background-color: #fbfbfb; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"> <Exceptions> </pre><pre style="background-color: #ffffff; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"> <Config> </pre><pre style="background-color: #fbfbfb; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px">  </pre><pre style="background-color: #ffffff; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"> <Code> clr </Code> </pre><pre style="background-color: #fbfbfb; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"> <Actions1> Log </Actions1> </pre><pre style="background-color: #ffffff; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"> <CustomActions1> .loadby sos mscorwks; !StopOnException System.ArgumentException 1; j ($t1 = 1) '.dump /ma /u ArgumentException.dmp; gn' ; 'gn'</CustomActions1> </pre><pre style="background-color: #fbfbfb; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"> <ReturnAction1> VOID </ReturnAction1> </pre><pre style="background-color: #ffffff; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"> <Actions2> Log </Actions2> </pre><pre style="background-color: #fbfbfb; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"> </Config> </pre><pre style="background-color: #ffffff; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"> </Exceptions> </pre><pre style="background-color: #fbfbfb; margin: 0em; width: 100%; font-family: consolas,'Courier New',courier,monospace; font-size: 12px"></ADPlus></pre></pre> Note that when you're troubleshooting a .NET 4 process, you need to replace ".loadby sos mscorwks" with ".loadby sos clr" in the CustomActions1-element of the configuration above. Then, invoke ADPlus with the following set of parameters. <code>C:\Program Files (x86)\Debugging Tools for Windows (x86)>cscript adplus.vbs -crash –p <PID> -FullOnFirst –c dump-on-argumentexception.cfg</code> Replace <PID> with the process ID you want to monitor, for example the w3wp.exe. ADPlus will launch, attach a console debugger to the process and take a memory dump each time the process throws an ArgumentException, even if it's handled (try/catched). <h2>Debugging the created memory dump(s)</h2> Open up WinDbg, and select File->Open Crash Dump... Navigate to one of the created dumps. Load the .NET debugging extension: <code>0:020> .loadby sos mscorwks</code> Note the 0:020? This is WinDbg's syntax of telling us which process:thread is currently active. In dumps with an active exception on one of its threads, WinDbg will automatically switch to the thread with the exception. Now, to see the stack trace including all available parameters and local variables, issue the following command: <code>0:020> !clrstack –a OS Thread Id: 0xdd1c (20) ESP       EIP  0b8ff600 66083e1c System.Web.HttpRuntime.ProcessRequestInternal(System.Web.HttpWorkerRequest)     PARAMETERS:         this = 0x02611d4c ... ...</code> Given this information, you may call SOS' !DumpObject command ("!do" for short) to examine the contents of 'this' or any other parameter that are still available (release mode binaries often optimize them away), and !DumpStackObjects ("!dso" for short) to enumerate all objects on the stack. Unfortunately, I don't have a memory dump that is perfectly suitable to demonstrate this. An out-of-context example would be this examination of the <a href="http://sdk.episerver.com/library/cms6.1/html/T_EPiServer_Core_LanguageManager.htm" target="_blank">LanguageManager</a>'s <a href="http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx" target="_blank">FileSystemWatcher</a> instance on the current thread. <code>0:020:x86> !dso OS Thread Id: 0x1524 (20) ESP/REG  Object   Name 000000000f16a624 000000000358c1d4 System.IO.FileSystemWatcher 000000000f16a67c 000000000358c1d4 System.IO.FileSystemWatcher 000000000f16a690 000000000358c1d4 System.IO.FileSystemWatcher 000000000f16a694 000000000358c1d4 System.IO.FileSystemWatcher 000000000f16a6f8 000000000358c1d4 System.IO.FileSystemWatcher 000000000f16a714 000000000358c1d4 System.IO.FileSystemWatcher 000000000f16a730 000000000358c1d4 System.IO.FileSystemWatcher 000000000f16a740 000000000358c1d4 System.IO.FileSystemWatcher 000000000f16a750 000000000358c030 EPiServer.Core.LanguageManager 000000000f16a75c 000000000358c030 EPiServer.Core.LanguageManager 000000000f16a768 000000000358bf28 System.Object 000000000f16a7a0 000000000357f0f4 EPiServer.Web.InitializeEngine+ActionState 000000000f16a7a4 000000000357ec8c EPiServer.Web.InitializeEngine 0:020:x86> !do 000000000358c1d4 Name: System.IO.FileSystemWatcher MethodTable: 000000000a2de9a4 EEClass: 000000000adb82b0 Size: 92(0x5c) bytes (C:\windows\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll) Fields:       MT    Field   Offset                 Type VT     Attr    Value Name 0000000060ad078c  400018a        4        System.Object  0 instance 0000000000000000 __identity 000000000a2dc594  40008e0        8 ...ponentModel.ISite  0 instance 0000000000000000 site 000000000ae0b3a4  40008e1        c ....EventHandlerList  0 instance 0000000000000000 events 0000000060ad078c  40008df      108        System.Object  0   static 000000001365be64 EventDisposed 0000000060ad0b70  400315f       10        System.String  0 instance 000000000358c044 directory 0000000060ad0b70  4003160       14        System.String  0 instance 000000000358c098 filter 0000000060aceb3c  4003161       18 ...es.SafeFileHandle  0 instance 0000000000000000 directoryHandle 000000000a2de708  4003162       34         System.Int32  1 instance       81 notifyFilters 0000000060aa463c  4003163       40       System.Boolean  1 instance        0 includeSubdirectories 0000000060aa463c  4003164       41       System.Boolean  1 instance        0 enabled 0000000060aa463c  4003165       42       System.Boolean  1 instance        0 initializing 0000000060ad2dbc  4003166       38         System.Int32  1 instance     8192 internalBufferSize 000000000a2de93c  4003167       48 ...tForChangedResult  1 instance 000000000358c21c changedResult 0000000060aa463c  4003168       43       System.Boolean  1 instance        0 isChanged 00000000084dd30c  4003169       1c ...SynchronizeInvoke  0 instance 0000000000000000 synchronizingObject 0000000060aa463c  400316a       44       System.Boolean  1 instance        0 readGranted 0000000060aa463c  400316b       45       System.Boolean  1 instance        1 disposed 0000000060ad2dbc  400316c       3c         System.Int32  1 instance        2 currentSession 000000000a2deb5c  400316d       20 ...ystemEventHandler  0 instance 0000000000000000 onChangedHandler 000000000a2deb5c  400316e       24 ...ystemEventHandler  0 instance 0000000000000000 onCreatedHandler 000000000a2deb5c  400316f       28 ...ystemEventHandler  0 instance 0000000000000000 onDeletedHandler 000000000a2dec40  4003170       2c ...namedEventHandler  0 instance 0000000000000000 onRenamedHandler 000000000a2dfd74  4003171       30 ...ErrorEventHandler  0 instance 0000000000000000 onErrorHandler 0000000060aa463c  4003172       46       System.Boolean  1 instance        1 stopListening 0000000060aa463c  4003173       47       System.Boolean  1 instance        0 runOnce 0000000060ad17a0  4003174      bc0        System.Char[]  0   static 000000001366d540 wildcards 0000000060ad2dbc  4003175      b08         System.Int32  1   static      383 notifyFiltersValidMask 0:020:x86> !do 000000000358c044 Name: System.String MethodTable: 0000000060ad0b70 EEClass: 000000006088d66c Size: 82(0x52) bytes (C:\windows\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll) String: C:\EPiServer\Sites\composer\lang Fields:       MT    Field   Offset                 Type VT     Attr    Value Name 0000000060ad2dbc  4000096        4         System.Int32  1 instance       33 m_arrayLength 0000000060ad2dbc  4000097        8         System.Int32  1 instance       32 m_stringLength 0000000060ad1850  4000098        c          System.Char  1 instance       43 m_firstChar 0000000060ad0b70  4000099       10        System.String  0   shared   static Empty     >> Domain:Value  0000000000798d20:00000000025b1198 0000000007f817e0:00000000025b1198 0000000007f81ca8:00000000025b1198 << 0000000060ad17a0  400009a       14        System.Char[]  0   shared   static WhitespaceChars     >> Domain:Value  0000000000798d20:00000000025b1788 0000000007f817e0:000000000266e0e0 0000000007f81ca8:00000000035a0794 << </code>2011-04-14T13:16:29.0000000Z

Blog post

Debugging a 64-bit dump of a 32-bit managed processYou may wonder: why on earth would you want to do that? Well, on 64-bit machines, 32-bit processes are run using a <a href="http://en.wikipedia.org/wiki/WOW64" target="_blank">WOW64</a> compatibility layer to provide the 32-bit process with the appropriate entry-points and map them to the 64-bit equivalents. <a href="/link/816929d4c75b4e23879d7b49ab720735.png"><img style="background-image: none; padding-left: 0px; padding-right: 0px; display: inline; padding-top: 0px; border-width: 0px;" title="image" src="/link/3c2851347fdc4470823a9632873349ed.png" border="0" alt="image" width="116" height="244" align="right" /></a>However, when you use Windows Vista's (and later) Create Dump File, you will create a dump of the process that includes the WOW64 compatibility layer. The dump file thus contain both 64-bit and 32-bit code. If you open this dump in WinDbg (x64), it seems to load just fine. Then, to start managed debugging, you will want to load the debugging extension <a href="http://msdn.microsoft.com/en-us/library/bb190764.aspx" target="_blank">SOS</a>. A convenient command to load the correct version of SOS (which must be the same version as the version of .NET Framework that you intend to debug) is to type the command <code>.loadby sos mscorwks</code> into the WinDbg command window. This will load SOS.dll from the same directory on your local machine, as mscorwks.dll was loaded from (in the debugee). (Note that you will need to exchange mscorwks with clr to debug a .NET4 debugee) However, in this case you will get errors such as: <code>0:000> .loadby sos mscorwks The call to LoadLibrary(C:\Windows\Microsoft.NET\Framework\v2.0.50727\sos) failed, Win32 error 0n193     "%1 is not a valid Win32 application." Please check your debugger configuration and/or network access.</code> There is some interesting information we can derive from this error message. Since the path (C:\Windows\Microsoft.NET\Framework) points to the 32-bit version of SOS.dll, the mscorwks.dll in the dump must also be a 32-bit binary (the 64-bit version of .NET Framework is in the Framework64 folder). And since we're running the 64-bit version of WinDbg and we try to load a 32-bit SOS, we will need to start a compatible version of WinDbg instead. Reopening the dump in WinDbg (x86) and loading the SOS managed debugging extension works just fine. However, you will find that it doesn't work when you issue any of the SOS commands: !CLRStack, !DumpHeap, !EEStack: <code>0:000> !clrstack Failed to load data access DLL, 0x80004005 Verify that 1) you have a recent build of the debugger (6.2.14 or newer)             2) the file mscordacwks.dll that matches your version of mscorwks.dll is                 in the version directory             3) or, if you are debugging a dump file, verify that the file                 mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.             4) you are debugging on the same architecture as the dump file.                 For example, an IA64 dump file must be debugged on an IA64                 machine. You can also run the debugger command .cordll to control the debugger's load of mscordacwks.dll.  .cordll -ve -u -l will do a verbose reload. If that succeeds, the SOS command should work on retry. If you are debugging a minidump, you need to make sure that your executable path is pointing to mscorwks.dll as well. </code> Drats! There's a workaround for this, though. Issue the command <code>0:000> !wow64exts.sw Switched to 32bit mode</code> And voila! <code>0:000:x86> !clrstack OS Thread Id: 0x1b40 (0) Failed to start stack walk: 80070057</code> Another failure... However, other commands have started to work! Among them EEStack which prints the stack trace for all active threads, with managed and unmanaged code interleaved. This will have to do. If you're able, capture dumps of 32-bit processes with a 32-bit debugger such as the 32-bit ADPlus part of the x86 version of <a href="http://msdn.microsoft.com/en-us/windows/hardware/gg463009" target="_blank">Debugging Tools for Windows</a>. Happy debugging!2011-04-13T14:30:00.0000000Z

Blog post

Symbols published for products in the R2 wave 2011The debugging symbols for the second release of EPiServer CMS, Community, Mail, Composer and Commerce have now been published on <a href="http://symbols.episerver.com/">http://symbols.episerver.com/</a>. Let me show you how to set up a few common debuggers to automatically download symbols from our store. <h3>Visual Studio 2008/2010</h3> Open up the Tools menu, and select Options… In the dialog that appears, open “Debugging” and select Symbols. Here, enter our symbol server location and a local directory for the symbol cache. <a href="/link/4f5021661cb34433bb9f67df1cf416bc.png"><img style="background-image: none; padding-left: 0px; padding-right: 0px; display: inline; padding-top: 0px; border: 0px;" title="image" src="/link/48dcf7c1cfb34be7814533829cf1fb0c.png" border="0" alt="image" width="471" height="272" /></a> With the symbols, the Call Stack window now displays a little bit more information: <a href="/link/6db1329f0da5493384274111423c72be.png"><img style="background-image: none; padding-left: 0px; padding-right: 0px; display: inline; padding-top: 0px; border: 0px;" title="image" src="/link/d6fde01fae43443ab7bba59bc34e32b2.png" border="0" alt="image" width="474" height="233" /></a> <h3>How to download the symbols for a set of EPiServer DLLs</h3> With the <a href="http://msdn.microsoft.com/en-us/library/ff558844%28v=vs.85%29.aspx">symchk.exe</a> tool, which is a part of <a href="http://msdn.microsoft.com/en-us/windows/hardware/gg463009">Debugging Tools for Windows</a>, you may obtain the symbols for a set of DLLs on your local machine. This is how you can download the EPiServer symbols for a web application. <ol> <li>Make sure you have <a href="http://msdn.microsoft.com/en-us/windows/hardware/gg463009">Debugging Tools for Windows</a> installed </li> <li>Open up a command prompt in the directory that contain the EPiServer DLLs whose symbols you want to obtain. </li> <li>Run the command "\Program Files\Debugging Tools for Windows (x86)\symchk.exe" *.dll /s SRV*<a href="http://symbols.episerver.com/">http://symbols.episerver.com/</a> /oc . You may need to adjust the path to the symchk.exe tool depending on your CPU architecture. </li> </ol> The parameter “*.dll” specifies that symbols for all DLLs in the current directory should be requested from the symbol server. The next parameter, /s SRV*http://symbols.episerver.com/, specifies which symbol path to use. The last parameter, /oc . tells the symchk.exe tool to output all the downloaded symbols to the current directory (alongside the DLLs). A typical AlloyTech bin folder looks like this just after the installation: <a href="/link/d3f6086498104fbbaa8ad7d95cc943c9.png"><img style="background-image: none; padding-left: 0px; padding-right: 0px; display: inline; padding-top: 0px; border: 0px;" title="image" src="/link/fc949d87452a4eae99fd755d2e68f6d7.png" border="0" alt="image" width="484" height="398" /></a> Using the symchk.exe tool, the symbols are downloaded from EPiServer’s symbol server to the current folder. <a href="/link/a2a828cc145c49d2b07bda4c0f93901b.png"><img style="background-image: none; padding-left: 0px; padding-right: 0px; display: inline; padding-top: 0px; border: 0px;" title="image" src="/link/c254fc01e2d6495f8ecace12b41f5293.png" border="0" alt="image" width="488" height="158" /></a> After the command has finished executing, the bin folder of the site have been populated with PDBs for all binaries that matched a symbol on our symbol server. <a href="/link/f574cdf8d03d4776a1e4fbcf2cfbac0d.png"><img style="background-image: none; padding-left: 0px; padding-right: 0px; display: inline; padding-top: 0px; border: 0px;" title="image" src="/link/d1aec30caa1c4b6fb1e5b790ff0ee3b7.png" border="0" alt="image" width="515" height="426" /></a> <h3>Configuring WinDBG</h3> Usually, you configure WinDBG’s symbol search path to include Microsoft’s Symbol Server. You may add EPiServer’s symbol store too, and search it as well as Microsoft’s symbol store. Just include SRV*C:\Symbols*http://symbols.episerver.com/ in the Symbol Search Path. Separate multiple entries with semi-colon. <a href="/link/8db2efb651aa48999fe7ce8e44192bb0.png"><img style="background-image: none; padding-left: 0px; padding-right: 0px; display: inline; padding-top: 0px; border: 0px;" title="image" src="/link/4823785194514a2ab81242bbae47dec0.png" border="0" alt="image" width="512" height="237" /></a> Happy debugging!2011-04-11T13:12:00.0000000Z

Blog post