Have i talked you about real life stories J… well here is another one. This time is about MOSS 2007 and InfoPath forms and about getting a new column for a promoted field that was already assigned to a Site column (resulting in duplicated Site Columns). This happens when you already have a published form, you make some changes to it, and then you deactivate the previous form, upload the changed one and reactivate it.

Why does this happen?

This option allows to view all the files that constitute the form. The next step was to compare the two versions and see if the differences could give us a clue. There it was, something odd! In one of the versions some column ID´s were not set in the manifest.xsf file.

Each of these entries on the table above relates to an entry like the one below, in the same file and are related by the columnName property:

<xsf:field name="Activity Number" columnName="{BD102547-0969-4045-A365-8FC1FEE85C0A}" node="/my:myFields/my:ActivityNumber" type="xsd:string"></xsf:field>.

When you make changes to an InfoPath form and some of those changes affect the field definitions, sometimes the InfoPath designer modifies the definition of those fields, changing the GUID of the field, and in some cases even clearing the GUID of that field. This causes the publishing process to create new columns, as it origins the relations between form fields and MOSS fields to break.

The workaround

Table 1: ListCTypeFields.ps1

The output for calling the script, for example for the content type SampleContentType, would be something like:

GAC    Version        Location                     

---    -------        --------
True   v2.0.50727     C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SharePoint_  
\12.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.dll

Selected Content Type:  Article Page

Id                                     Title

------------------------------------   -----------------------------

  c042a256-787d-4a6f-8a8a-cf6ab767f12d   Activity Number
  5f47e085-2150-41dc-b661-442f3027f552   Audit Status
  8553196d-ec8d-4564-9861-3dbe931050c8   Start Date
  8c06beca-0777-48f7-91c7-6da68bc07b69   End Date
  fa564e0f-0c70-4ab9-b863-0177e6ddd247   Audit Title
  28cf69c5-fa48-462a-b5cd-27b6f9d2bd5f   Auditors

</xsf:fields>

…

<xsf2:listPropertiesExtension>
  <xsf2:listPropertiesExtension>
    <xsf2:fieldsExtension>
      <xsf2:fieldsExtension>
        <xsf2:fieldExtension columnId="c042a256-787d-4a6f-8a8a-cf6ab767f12d" readWrite="no" 
columnName="{BD102547-0969-4045-A365-8FC1FEE85C0A}"></xsf2:fieldExtension>
        <xsf2:fieldExtension columnId="5f47e085-2150-41dc-b661-442f3027f552" readWrite="no" 
columnName="{7D192010-DB9C-4E86-B4D8-D7F68B3C2FCC}"></xsf2:fieldExtension>
        <xsf2:fieldExtension columnId="8553196d-ec8d-4564-9861-3dbe931050c8" readWrite="no" 
columnName="{35387C25-2634-41A8-A866-C26B1AD30827}"></xsf2:fieldExtension>
        <xsf2:fieldExtension columnId="8c06beca-0777-48f7-91c7-6da68bc07b69" readWrite="no" 
columnName="{D6C10D8E-0A84-4C01-B275-DCBCB45EF995}"></xsf2:fieldExtension>
        <xsf2:fieldExtension columnId="fa564e0f-0c70-4ab9-b863-0177e6ddd247" readWrite="no" 
columnName="{EF224E14-E324-47D4-9345-0BC24BF3E781}"></xsf2:fieldExtension>
        <xsf2:fieldExtension columnId="28cf69c5-fa48-462a-b5cd-27b6f9d2bd5f" readWrite="no" 
columnName="{185F33F0-C353-46C8-BC9A-11529D9D10C6}"></xsf2:fieldExtension>
      </xsf2:fieldsExtension>
    </xsf2:fieldsExtension>
  </xsf2:listPropertiesExtension>

This way the duplicated fields problem is solved and the correct field will be associated to the correct Site Column. All that is left to do is to save the form as a .xsn file again and publish it.

See you next time…

Rui Veloso

Don’t get me wrong, I’m not talking only about technical knowledge. My goal for this post is to reflect on how is the troubleshooting process usually done, the different approaches and the pros and cons of each, and also the different steps in each approach.

I’m not really following any methodology or have read any literature about this topic, I’m just venting and putting out some of the experiences I’ve had in the past.

“Houston, we have a problem.”

Something similar to this is frequently heard at 9am or 5pm. I’m not sure if there is a statistical correlation between time of the day and problem occurrence, but I do know that the person carrying the message will most likely:

a) not have any information about the problem, except for the fact that he/she has one;

b) not tell you the correct information about the problem;

c) include several problems in one;

d) be very, very nervous or under pressure.

Points a), b) and c) all relate to the way the problem is characterized and scoped, in the next section. Point d) will need some management skills to keep the information flowing and prevent everyone involved from panic. Let’s think about each one of these topics in detail.

Detailing the issue

Gathering and organizing the information is one of the most critical steps in the whole process. Your very first step is to find out what is, in fact, the issue. Some crucial question arise here such as:

- What is the impact of issue?

- Does it affect every user?

- What symptoms are you seeing?

- Is it happening all the time?

- Is it happening now?

- Has it happened before? How did we fix it back then? (a good knowledge base is helpful here)

- Was there some change to the system lately? (a good change management process is helpful here)

- What actions have you already taken?

- Is your goal a root-cause analysis or just restoring the service? (setting the expectations with this question is important and may save you from some political problems later)

I find myself faced with systems I don’t know anything about, so identifying the architecture pieces and the way the problematic feature works with each is relevant. This will give you an idea of the machines, products, technologies and dependencies involved and may even give you some hints on the cause of the problem. You don’t need to go into the details of every machine, but typical information such as OS, patch level and the way the information flows between systems (identifying who is the client and server and the protocols involved) should be included.

If the problem is affecting just some of the different components of the system, breaking it down and defining the dependencies will allow you to choose which area to check first.

If you’re handling a really critical situation, then point d) above comes into play and you should worry about communication. Try to keep everyone aligned for example by drawing the picture of the system and listing the symptoms on a board. This is probably not the best time to stop and write an e-mail unless you have someone who can help you with that.

Defining an action plan

Assuming that you’ve got the information above and you trust it to be true, you should have a clearer picture of what are the users experiencing which is not the normal behavior of the system. Your next step, then, is to set up an action plan to start attacking the problem.

The action plan must start with a clear goal, i.e, what are you trying to gather, prove or fix, and then include the steps that will be taken to achieve that goal. Remember the communication concerns we mentioned before? Well, if you keep everyone up-to-date and aligned in terms of the actions that will be performed and the goals that we want to achieve, it will probably help reduce the tension and make everyone work together. Note that there may not be a single possible action plan nor will your first goal be "solve the issue”. After all, if you knew the cause of the problem, it would be easy to fix it, right?

If your plan has the goal of solving the issue, for example through some configuration change, how can you measure if the issue was solved? What are you metrics? Hard and factual data is relevant here, because it will prove the issue is gone.

There are different approaches to investigating a problem. If you’re really comfortable about the technology or system and you suspect some part of it to be the root cause, you could take a bottom-up approach and start by going really deep on one or only a few components. If your gut feeling is right, then this will be a fast path to success, but if it’s wrong it could prove to be a waste of time. Being able to do this takes some experience with the technology and a good set of similar problems in your luggage.

The opposite approach is obviously the top-down approach. It starts by taking a look at indicators and monitoring from the systems at a very high level and try to dig deeper when you find something strange. If you don’t know where to start, this might be a good way to organize the work, but it may take you some time to actually get to the core of things and be able to find out interesting information.

Another possible way to plan your work is something I find quite similar to binary searching. Like in the algorithm, try to divide the system in half (or at least in large enough parts) and work top-down on each one. If you find that a certain part of the system is working correctly then you can rule them out completely and focus on the other side. If you can isolate some components, then it’s easier to choose to ones you want to dig into. I try using this pattern when I’m troubleshooting because I feel it’s usually more effective. It requires a good knowledge of the way different components interface and communicate, especially transport and data protocols, and which monitoring and logging data is associated with the interface mechanisms.

Regardless of your chosen approach, follow your action plan, gather the information you needed and proceed to the next step.

Evaluate your last move

Once you’ve achieved the goal established for the action plan, it’s time to evaluate what was done and the information that was collected. Here, you need to recall the goals you established for your action plan. Were they accomplished?

If your plans were to gather more information, then what does that information show? Does it point to a suspect or is everything looking normal? If you were planning to change some setting and fix the problem, did it work?

Start over or celebrate!

Troubleshooting, much like the scientific method, is an iterative task and it may require you to go through the last 2 steps several times before you understand what’s going on.

If your action plan did not work or if only showed the need for further actions, plan them the same way you did before and set the wheels in motion. If your problem is gone, then your work is done.

At this point, it may be a good idea to debrief and discuss what happened and to work proactively on how the problem can be prevented or at least predicted. This way, you’ll learn something from the situation that can potentially save time, money and the day later on.

These were my thoughts on managing troubleshooting processes based on my personal experience. Feel free to comment and share yours.

(cross-post from https://blogs.msdn.com/ricardo)

Ok, so it seems that the suggestion is not good enough. What can you do if all you have is this error message and a complaining user? Well, there is often a log file of some kind which you should be able to open up and correlate the error occurrences with some kind of a timestamp. Looking at the Event Viewer events is also a good first stop in case some relevant message is logged for that matter.

As a troubleshooter, though, you do not want to rely upon the unpredictability of those sources of data as far as your problem is concerned. You should be able to open your bag of tools and start digging in until you find the root cause. Depending on the nature of applications and technologies under your scope, this bag of tools may vary a lot. Let me describe my approach for this particular issue.

After figuring out that no additional information was being logged anywhere, I used the good ol’ Process Monitor and asked the user to reproduce the issue, as it happened every time.

Let’s follow the trace and try figuring out what was happening:

At this stage, the worker process was loading this 401-1.htm file, so this was probably during the security handshake in which there is a credentials challenge and response process. No harm done here, eventually the credentials are accepted and the request proceeds.

There you go, the request is being processed. Apparently, the worker process is now trying to connect to a SQL Server instance in a server named SRV09. If you’re not acquainted with the solution architecture, this is a good clue of where the data is being stored and retrieved from.

Next I had to scroll down a bit as there were tons of MUI-related events which do not add much. And then, I found these 3 lines:

Something must have gone wrong within those 30 milliseconds.

Let’s see what follows:

Indeed, something has gone wrong... Where? Well, this HKCR\CLSID\{0C7FF16C-38E3-11d0-97AB-00C04FC2AD98} is the SQLOLEDB CLSID, meaning that we can move on to SQL Server and figure out what is going on there.

By moving on to SQL Server, I mean starting a SQL Server trace on this SRV09, ensuring that OLEDB Errors is selected, as well as those basic events you’ll find in the usual templates concerning the SQL Statements execution.

Weird: according to https://technet.microsoft.com/en-us/library/cc917589.aspx, this exception stands for Too many arguments were supplied for procedure %. *ls, something we would not expect to happen in a Windows SharePoint Services/SQL Server environment. Anyway, by checking the statement which starts before the exception and gets completed immediately after it, we saw that the call did not really match the Stored Procedure signature.

In particular, the SP was expecting fewer parameters, thus the exception above. Given this mismatch, I suspected of an incomplete WSS patching or update, a plausible reason for this, as the code might have been changed along with the database schema and Stored Procedure implementation. Bulls-eye!! A few weeks before, this particular WSS server had been applied the latest Service Pack, and apparently that did not succeed, but no one noticed until this user tried to add a new field to a list.

See? No logs, no events, no hands on the steering wheel, just valuable information popping out of these great tools...

Regards,

Manuel Oliveira

A very interesting way to achieve this is by using a combination of a very well-known tool, Fiddler, and a somewhat unknown tool called Http Replay. With these tools, we’ll work on creating an offline mirror of the browsing experience of a site, that can easily be packaged and sent to a developer for a more detailed look.

We’ll start by downloading and installing the tools. Just go here and here and get the bits to your machine. Then, execute both installers to setup the applications.

Our next step is to gather a Fiddler trace. This is something most web application developers are used to, so it should be familiar to you. Just fire up Fiddler and navigate to your desired web site.

The goal here is to visit every page and resource that you want to make available offline, so be sure to clear your browser cache before start collecting data so that all images and javascript files, which are normally cached are actually loaded and, therefore, show up on the Fiddler trace.

Here’s a sample of Fiddler after tracing www.microsoft.com:

Now, create a trace file, going to File, Save All Sessions and storing the saz file somewhere on your hard drive. This file holds all the necessary information for HTTP Replay to mimic www.microsoft.com offline, which is what we’ll do next.

HTTP Replay works as an HTTP proxy that either returns the stored response for an HTTP request it knows (because it’s stored on some trace file) or forwards the request to the actual server, if available.

To replay from a Fiddler log, you’ll need to:

- rename the "SAZ" file to "ZIP"

- extract the "raw" directory

- run HTTPREPLAY.CMD passing the "raw" directory as the logfilename

To start HTTP Replay, open a command prompt and cd to C:\Program Files\HTTPREPLAY or C:\Program Files (x86)\HTTPREPLAY on an x64 system. Next, execute a command similar to HTTPREPLAY.CMD <logfilename>, for example, HTTPREPLAY.CMD C:\temp\raw.

This is will fire up a browser that shows the requests contained in the trace file provided. It should be similar to this:

Note that these are the same requests that the Fiddler trace contained and that the screenshot above showed.

Now, just follow the instructions on the page: clear your browser cache, change the proxy to localhost:81 and click on the first link. For each request, the command prompt running HTTP Replay will show some output like this:

23:30:39:040 #0 - New connection accepted (127.0.0.1:64308)

23:30:39:083 #0 - 127.0.0.1:64308 -> :81 (2691 bytes / total : 2691 bytes)

23:30:39:084 #0 - GET https://www.microsoft.com/ [FOUND]

Each time a request is FOUND, it is returned from the trace file which is disconnected from the server. With this tool and the above steps, you can now replicate your site’s behavior and troubleshoot client-side easily.

As a last note, there are some interesting settings that you can use for HTTP Replay, the most interesting of which is the RESPECTTIMINGS option which makes HTTP Replay take as much time as the original request took to serve the response. However, for this you can’t use a Fiddler trace and you must use another tool called STRACE.

- Ricardo Henriques

(cross-post from https://blogs.msdn.com/ricardo)

After debugging for quite some time, and looking almost every day at memory dumps you start to think “I really need a command to this, to do that,…” in order to easy on some of the repetitive work and allow you to more quickly focus on the issue itself.

I find debuggers scripts to be a big advantage here, and use them a lot. These are pretty simple to define and use (don´t confuse with debugger extensions. That’s another history). So there are quite a few I keep at hand to ease the pain on some manual work.

The sample I’m going to provide is one of the scripts I use most and allows you to understand what needs to be defined and loaded on the debugger.

The purpose on this sample is to find some string on the ouput of a debugger command. Syntax will be

Find “ExecuteCommand” “value_to_find”

The output will all lines that contain value_to_find

First, all you need is notepad. Open notepad and paste the following line

Save the file as find.txt and place it on a folder.

Next step is to load this script on the debugger. Open windbg.exe and load a memory dump. Below is a sample on how to invoke my script with two parameters and the output that was returned.

I will leave it as an exercise another very useful script that is to count the number of occurrences of value on input command.

Have fun

Bruno

 A while ago when I arrived to a customer site, he came to me and told me that he had a problem in his MOSS 2007 Server Farm, that for 3 days no one was able to access one of the intranet main site nor any of it sub-sites. The error was:

 500 INTERNAL SERVER ERROR

 When I asked him what append to cause the problem, no one knew to answer. So I started analyzing the problem. To start with I accessed the customer site and used Site Content and structure to check the structure of the site:

Figure 1 - Scenario created only for purpose of this post

 When navigating the tree of the Site Content and Structure it was perfect form the structure point of view, and I was able to navigate on the structure without any issue. But when I tried to do any other kind of action like Open Link in New Window or creating a new item there was the issue again.

 500 INTERNAL SERVER ERROR

 The next thing was to look at the URL and there was something funny, no matter the action called on the HugeSite_LotsOfSubsites or one of its sub-site I would end up with the same URL https://intranetSite/HugeSite_LotsOfSubsites.aspx/Pages/default.aspx.

Analyzing the URL I noticed 2 .ASPX in the same URL K https://intranetSite/HugeSite_LotsOfSubsites.aspx/Pages/default.aspx, and “there is the problem…“. It was the problem, alright, but how was it caused and how to solve it. Talking to the customer I showed him only the URL the site (https://intranetSite/HugeSite_LotsOfSubsites.aspx) and pointed that this should be the problem. After that moment our conversation was more or less like this:

 Me: This is the url that is causing the problem https://intranetSite/HugeSite_LotsOfSubsites.aspx

Customer: That is an aspx page.

Me: No, this is your current site URL.

Customer: No, that is an aspx page.

…

You get the idea J…

 Just after our chat he remembered that some user was changing some Site Title´s and Url Name´s using the General Settings feature like the images below:  

 The cause was found in the Url Name: text box, someone wrote HugeSite_LotsOfSubsites.aspx instead of just HugeSite_LotsOfSubsites, making this site inaccessible and all of its child sites. Now we had to find a solution, because using General Settings of the site to correct it was out of question, since any action on HugeSite_LotsOfSubsites would cause the ….

 500 INTERNAL SERVER ERROR

 In a previous conversation the customer had told me that restoring the backup should be our last resort, because the problem started 3 days ago, the sites that were working continued to be changed by users. So all I had left was the powerful SharePoint object model J.

 To validate the assumptions made before, I did a console application to validate the ServerRelativeUrl of SPWeb in question:  

Code 1 - Validating in C#

The equivalent in Windows PowerShell is:  

Code 2 - Validating in Windows PowerShell

 The result was:

 
All that was left to do was using correcting the URL with some simple code like the following in C# that would change the ServerRelativeUrl of SPWeb object in question:  

Code 3 - Correcting the problem C#

 An even easier way to do it was to use Windows PowerShell to do the same thing:  

Code 4 - Correcting the problem Windows PowerShell

 With this, the problem was solved without having to restore the 3 days ago backup. This was a problem easy to troubleshoot and to fix, thanks to the flexibility of the SharePoint object model. This also shows that SharePoint being so flexible makes it easy for less experienced users to do big damage if they have sufficient privileges to do it. With this post I also wanted to show you how easy can be using SharePoint API with PowerShell, and more important of all never name a Sharepoint site ending in .ASPX.   

 See you next time!

 Rui Veloso

Let me start by clarifying that this only applies to x86. The reason for this is that on x86 the first field on a CONTEXT (more info at https://msdn.microsoft.com/en-us/library/ms679284 ) structure is a flag with the value 0x1003f.

More often than I desire I get memory dumps (in hang mode) when an exception occurs and someone complains their application is not working for the last 24 hours. Before I throw the ball back and ask crash dumps I always give it a shot to see if I’m lucky enough and the memory dump collected contains any remains or clues that would allow me to explain or get closer to the resolution of the problem.

I´m not covering managed exceptions. To those you can use SOS or the recently released psscor2 (https://www.microsoft.com/downloads/details.aspx?FamilyID=5c068e9f-ebfe-48a5-8b2f-0ad6ab454ad4&displayLang=en). As a side note I highly recommend psscor2 if you are debugging managed code. For more info on this extension and commands, give a look at Tom blog (https://blogs.msdn.com/b/tom).

Now, back to our scenario. Whenever an exception occurs, the CONTEXT is pushed on the stack so our goal would be to see if any traces of 0x1003f still exist on stack. Below is an example using s (search memory). For more information on s command please refer to debugging tools for windows help.

Now take the yellow address above and use .cxr to set context

Let’s look at the stack after using .cxr

Just for reference this thread stack is

So, bottom line if you are lucky enough J some info might still be present and give clues to the issue being debugged.

Bruno

Sure, I’ll briefly present the procedure, but what I really want to show is how easily we can assess, in our development machines, the splash screen the end user will experience.

Default Loading Experience in Silverlight

It is fairly easy to build our own splash screen in Silverlight but, surprisingly, sometimes even the best and highly polished Silverlight applications overlook this.

Without a customized splash screen the default loading experience is the well-known light-blue circle animation.

There’s nothing wrong with it but if you’re building an amazing, unique, matchless Silverlight application you’ll certainly want the loading experience to be up to it, blending nicely with your brand and design.

Custom Loading Experience in Silverlight

How to customize it then? - As promised, I’ll be concise here: A straightforward 1, 2, 3 steps.

To learn more about Silverlight Splash Screens please read this article: https://msdn.microsoft.com/en-us/library/cc838130(v=VS.95).aspx

Step 1 - Build your XAML Splash Screen and place it on your Web Site

Be as creative as you wish. Just don’t define a UserControl in your XAML - it won’t work. Use a Layout Control (as a Grid, StackPanel or Canvas) as the top element.

The XAML file must be outside the package. Otherwise, it won’t be available while the package itself is downloading.

Example: SplashScreen.xaml

Step 2 - Specify the custom Splash Screen in the Silverlight Plugin Host

Use following params options:

SplashScreenSource - URI of the XAML page that provides the visuals for the splash screen.

OnSourceDownloadProgressChanged – (Optional) Name of an event handler that is called at increments during the time that the Source is being downloaded.

OnSourceDownloadComplete – (Optional) Name of an event handler that is called once when the Source download is completed.

Example:

<object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%">
      (...)
      <param name="splashscreensource" value="SplashScreen.xaml" />
      <param name="onSourceDownloadProgressChanged" value="onSourceDownloadProgressChanged" />
      <param name="onSourceDownloadComplete" value="onSourceDownloadComplete" />
</object>
 

Step 3 - (Optional) Implement Javascript Event Handlers

If you want to programmatically change your Splash Screen when the source package is downloading, e.g. display the loading percentage, or act when the download is complete implement these handlers (create a .js file and reference it on your page or write the script within the HTML head tag).

Example:

<script type="text/javascript">
        function onSourceDownloadProgressChanged(sender, eventArgs) {
            var slPlugin = sender.getHost();
            slPlugin.content.findName("LoadingText").Text =
                Math.round((eventArgs.progress * 100)) + "%";
        }

        function onSourceDownloadComplete(sender, eventArgs) {
            window.status = "Finished";
        }
</script>
 

Seeing it in Action

If you followed these instructions you should experience a loading sequence like this:

However, probably you won’t! That’s not because something is wrong, it just isn’t displayed because you’re most likely running it locally and your XAP package loads too fast. The XAML-based splash screen will only be showed if it exceeds a certain time threshold (approximately 0.5 seconds).

How can we test it then? How can we simulate what the end user will most certainly experience, from the other side of the world, with network latency and bandwidth constraints?

Fortunately, we won’t need fancy network tools to do it (unless we really want to simulate different network conditions – here we just want to be able to see the splash screen running). All we need is our “old pal” Fiddler (Fiddler is a freeware Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet).

How to Use Fiddler to Slow Down XAP Loading

To introduce some latency when the browser is downloading the package we should configure a Fiddler rule.

In Fiddler, select “Rules > Customize Rules...”

A CustomRules.js file will be opened. Here you should search for the OnBeforeRequest function and add a Session delay to your XAP file download. Don’t forget to save the file before testing.

Example:

static function OnBeforeRequest(oSession: Session)
{
    if (oSession.uriContains("Load.xap")){
         oSession["ui-color"]="orange"; 
         oSession["ui-bold"]="true";
         //Delay received data by X ms per KB downloaded.
         oSession["response-trickle-delay"] = "2000"; 
    }
(…)
}

Here, for the Load.xap request, I’m setting the Fiddler request trace line to bold orange and introducing a 2000ms delay per KB downloaded.

Now, having Fiddler running, capturing traffic with this custom rule, we should be able to see our Splash Screen when browsing the Silverlight application.

Well… it depends! It will still not work if you’re using a local address or the Visual Studio Built-in Web Server, browsing https://localhost or https://127.0.1.1

The reason for this is that local addresses typically bypass any proxies and so Fiddler will not be able to monitor these requests.

Solution:

· Local addresses

Instead of using a local address use the Machine name or the local IP address.

This is, instead of https://localhost or https://127.0.1.1 use https://mymachinename or https://192.168.1.100 (your IP address).

· Visual Studio Built-in Web Server

Instead of using a local address use a hack: A dot suffixing 127.0.0.1 ! That’s right, access the application through https://127.0.0.1. ! Awkward? True, but works :)

Now Fiddler will be able to monitor these requests and the rule will do its work. You’ll see something like this:

And of course, as intended, you’ll be able to watch your custom Splash Screen in action!

Regards.

Pedro Fortes

Sometimes i have to do live debugging in order to understand what’s going on inside a process. Usually when this happens i need to set breakpoints on specific methods. Let’s say that I what to set a specific breakpoint on a method inside Microsoft.Sharepoint.dll (this is just an example, the same applies to every managed dll).

First thing I do is to list domains using !DumpDomain. The output is somewhat similar to below (I’m interested on modules address and modules names)

Assembly: 000000000018a850 [C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SharePoint\12.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.dll]

ClassLoader: 0000000007852980

SecurityDescriptor: 000000000230da48

  Module Name

00000642800c2e30 C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SharePoint\12.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.dll

Assembly: 000000001fd54b50 [C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\48d21411\ee495e7c\App_Browsers.pprtnn5a.dll]

ClassLoader: 00000000684cf630

SecurityDescriptor: 000000000230da48

  Module Name

000006428311a8a8 C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\48d21411\ee495e7c\App_Browsers.pprtnn5a.dll

Now that I know the module address of the module i´m interested in lets dig into the types it defines. To do that use !DumpModule –mt <module address>

The output is similar to the one below

0:000> !DumpModule -mt 00000642800c2e30

Name: C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SharePoint\12.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.dll

Attributes: PEFile

Assembly: 000000000018a850

LoaderHeap: 0000000000000000

TypeDefToMethodTableMap: 0000064280250020

TypeRefToMethodTableMap: 00000642802568c0

MethodDefToDescMap: 0000064280259028

FieldDefToDescMap: 0000064280291958

MemberRefToDescMap: 0000064280302c18

FileReferencesMap: 00000642803108c8

AssemblyReferencesMap: 00000642803108d0

MetaData start address: 000000000af87fac (6417184 bytes)

Types defined in this module

              MT    TypeDef Name

------------------------------------------------------------------------------

0000064280cd64c0 0x02000002 DotfuscatorAttribute

0000064280cd6600 0x02000003 Microsoft.SharePoint.CoreResource

00000642808e4640 0x02000004 Microsoft.SharePoint.Library.SPRequest

00000642809ff400 0x02000005 Microsoft.SharePoint.Library.SPCharArray

0000064280cd67c0 0x02000006 Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy

0000064280cd6980 0x02000007 Microsoft.SharePoint.DirectorySoap.ContactFlags

0000064280cd6b00 0x02000008 Microsoft.SharePoint.DirectorySoap.RequestStatus

0000064280cd6d40 0x02000009 Microsoft.SharePoint.DirectorySoap.RequestInfo

0000064280cd6f00 0x0200000a Microsoft.SharePoint.DirectorySoap.RequestResponse

0000064280cd7000 0x0200000b Microsoft.SharePoint.DirectorySoap.DistributionGroupFlags

(…)

Types referenced in this module

              MT    TypeRef Name

------------------------------------------------------------------------------

00000642788c0cd8 0x01000011 System.Object

000006424bb22900 0x01000012 System.Web.Services.Protocols.SoapHttpClientProtocol

00000642788c10b8 0x01000013 System.Enum

00000642bcf23248 0x01000014 System.Web.SiteMapProvider

00000642bcf7b298 0x01000015 System.Web.UI.IHierarchicalDataSource

(…)

Now let’s say i´m interested on type Microsoft.SharePoint.DirectorySoap.RequestInfo. To list all methods use !DumpMT –md <mt address>

0:000> !DumpMT -md 0000064280cd6d40

EEClass: 0000064280d01848

Module: 00000642800c2e30

Name: Microsoft.SharePoint.DirectorySoap.RequestInfo

mdToken: 02000009  (C:\WINDOWS\assembly\GAC_MSIL\Microsoft.SharePoint\12.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.dll)

BaseSize: 0x30

ComponentSize: 0x0

Number of IFaces in IFaceMap: 0

Slots in VTable: 11

--------------------------------------

MethodDesc Table

           Entry       MethodDesc              JIT Name

000006427809f660 0000064278930388   PreJIT System.Object.ToString()

000006427809dc60 0000064278930390   PreJIT System.Object.Equals(System.Object)

000006427809dc90 00000642789303a8   PreJIT System.Object.GetHashCode()

0000064278092ca0 00000642789303b0   PreJIT System.Object.Finalize()

0000064280ce12f0 0000064280cd6c90     NONE Microsoft.SharePoint.DirectorySoap.RequestInfo.get_RequestorEmail()

0000064280ce12f8 0000064280cd6c98     NONE Microsoft.SharePoint.DirectorySoap.RequestInfo.set_RequestorEmail(System.String)

0000064280ce1300 0000064280cd6ca0     NONE Microsoft.SharePoint.DirectorySoap.RequestInfo.get_Justification()

0000064280ce1308 0000064280cd6ca8     NONE Microsoft.SharePoint.DirectorySoap.RequestInfo.set_Justification(System.String)

0000064280ce1310 0000064280cd6cb0     NONE Microsoft.SharePoint.DirectorySoap.RequestInfo.get_RequestId()

0000064280ce1318 0000064280cd6cb8     NONE Microsoft.SharePoint.DirectorySoap.RequestInfo.set_RequestId(System.Guid)

0000064280ce1320 0000064280cd6cc0     NONE Microsoft.SharePoint.DirectorySoap.RequestInfo..ctor()

This shows some very interesting info like MethodDesc (used to set breakpoints) and JIT information. To set a breakpoint just use !bpmd –md <methoddesc>

0:000> !bpmd -md 00000642789303b0 

Now you can press “g” (go) and let the breakpoint be hit.

Have fun

Bruno

This time I’m going to address something that most times is somewhat straight forward to analyze yet many people I deal with don´t know how to proceed when a blue screen appears. In this blog post I assume the server is already configured to generate kernel dumps or mini dumps. (this is something I always advice. Configure your servers to generate memory dumps if something goes wrong)

Usually I get emails like “my server just got a BSOD (blue screen of death). I´ve got a minidump and I need to understand what happened”. My approach is always the same (and most of the times it is enough to find the root cause).

First Step

Open windbg and make sure the symbol server is properly configured – more info at https://www.microsoft.com/whdc/devtools/debugging/debugstart.mspx

Second Step

Open the memory dump on windbg. Below is the output when opening a kernel memory dump

(…)

Loading Kernel Symbols

...............................................................

................................................................

......................

Loading User Symbols

Loading unloaded module list

....................................

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 50, {d44cdde4, 0, 818ed8b3, 0}

(…)

As you can see above the debuggers states “Use !analyze –v to get detailed debugging information”. Let’s follow the expert J (the debugger) and issue !analyze –v

1: kd> !analyze -v

*******************************************************************************

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)

Invalid system memory was referenced.  This cannot be protected by try-except,

it must be protected by a Probe.  Typically the address is just plain bad or it

is pointing at freed memory.

Arguments:

Arg1: d44cdde4, memory referenced.

Arg2: 00000000, value 0 = read operation, 1 = write operation.

Arg3: 818ed8b3, If non-zero, the instruction address which referenced the bad memory

                    address.

Arg4: 00000000, (reserved)

Debugging Details:

------------------

(…)

TRAP_FRAME:  d28db9e0 -- (.trap 0xffffffffd28db9e0)

ErrCode = 00000000

eax=d44cdde0 ebx=d28dbad0 ecx=d28dba94 edx=00000000 esi=b2a6c298 edi=09f56e20

eip=818ed8b3 esp=d28dba54 ebp=d28dba60 iopl=0         nv up ei ng nz na po nc

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010282

nt!RtlTimeToSecondsSince1980+0x16:

818ed8b3 ff7004          push    dword ptr [eax+4]    ds:0023:d44cdde4=????????

Resetting default scope

LAST_CONTROL_TRANSFER:  from 8185edb4 to 818a936d

STACK_TEXT: 

d28db9c8 8185edb4 00000000 d44cdde4 00000000 nt!MmAccessFault+0x10a

d28db9c8 818ed8b3 00000000 d44cdde4 00000000 nt!KiTrap0E+0xdc

d28dba60 a658794a d44cdde0 d28dba94 b2a6c298 nt!RtlTimeToSecondsSince1980+0x16

d28dba9c a6586d85 bfca9448 b2a6c298 00000020 srvnet!FillSessionInfoBuffer+0x8c

d28dbae4 a6587be7 bfca9448 00000007 00000006 srvnet!SvcEnumApiHandler64+0x7f

d28dbb10 a657bb5a bfca9448 09f56d60 00002000 srvnet!SvcSessionEnum+0x2f

d28dbb6c a658c102 87629550 00000001 10b017e8 srvnet!SrvAdminProcessFsctl+0x2de

d28dbbd0 a657c3aa 87629550 00000001 10b017e8 srvnet!SrvNetProcessFsctl+0x54

d28dbc18 a658c043 872aaf08 00146027 87629550 srvnet!SrvNetDeviceControl+0xc6

d28dbc2c 81855976 872aaf08 c5e69880 c5e69880 srvnet!SrvNetDefaultDispatch+0x3e

d28dbc44 81a576a1 87629550 c5e69880 c5e698f0 nt!IofCallDriver+0x63

d28dbc64 81a57e46 872aaf08 87629550 10b01701 nt!IopSynchronousServiceTail+0x1d9

d28dbd00 81a56b2c 872aaf08 c5e69880 00000000 nt!IopXxxControlFile+0x6b7

d28dbd34 8185bc7a 000007a8 000033a4 00000000 nt!NtFsControlFile+0x2a

d28dbd34 77275e74 000007a8 000033a4 00000000 nt!KiFastCallEntry+0x12a

WARNING: Frame IP not in any known module. Following frames may be wrong.

043bf878 00000000 00000000 00000000 00000000 0x77275e74

(…)

MODULE_NAME: srvnet

IMAGE_NAME:  srvnet.sys

(…)

I usually look at the highlighted above:

·        Error – PAGE_FAULT_IN_NONPAGED_AREA

·        Stack – STACK_TEXT

·        IMAGE_NAME

Next step is to see what is the version of the module (in my sample srvnet)

1: kd> lmvm srvnet

(…)

    FileVersion:      6.0.6002.18005

(…)

And finally bing it (https://www.bing.com/search?q=%22PAGE_FAULT_IN_NONPAGED_AREA%22+srvnet+msdn&go=&form=QBRE&filt=all)  with some keywords (depending on results I try one or more combinations like including method name, …)

"PAGE_FAULT_IN_NONPAGED_AREA" srvnet msdn

In my case the first link is to https://support.microsoft.com/kb/951418. After installing the hotfix the issue no longer occurs.

Of course it´s not always as simple as this but most times it’s enough.

See you next time

Bruno