The CRM Grid – A Microsoft CRM Blog

Greg Owens’ rose-tinted MS-CRM mumblings

Archive for crm

Windows Update killed my app pool!

Tried to access my client’s development server today to find that CRM 4.0 was down. First thing I did was to check IIS, to find that the CRMAppPool was stopped. I tried to restart it – it looked like it had worked, but alas a refresh showed that it had failed to start properly.

After first blaming the client’s visiting tech who was also working on the server (sorry ‘Cheung!), I checked the Event Viewer and the System Log showed a series of messages from my attempt to restart the Application Pool:

A process serving application pool ‘CRMAppPool’ terminated unexpectedly. The process id was ‘3432’. The process exit code was ‘0xffffffff’.

After a few attempts, W3SVC had given up:

Application pool ‘CRMAppPool’ is being automatically disabled due to a series of failures in the process(es) serving that application pool.

Scrolling down, it became clear that the new prime suspect was Windows Update. A number of updates had been installed early this morning. I checked the KB articles for each one until I came across KB973917 (Extended Protection for Authentication in Internet Information Services). I read the article and although some extra configuration was required, it didn’t seem to fit my scenario (aka, this is a development server and there was a lot of text in the article and I needed to get back to development, rather than poncing about with security updates). The solution for me was to simply uninstall KB973917 and reboot the server.

Microsoft Dynamics CRM 4.0 is now working just fine, though this probably needs some more investigation. I quick straw poll of some of my CRM buddies did not suggest a widespread issue (yet?) but maybe this was because of the particular setup we are using here?

I’m not about to fully troubleshoot now, but here is some information about the server that was stricken – maybe it will help you all to pinpoint any issue with your own servers:

    Microsoft Dynamics CRM 4.0 – Update Rollup 5
    Microsoft Windows 2003 SP2
    Internet Information Services 6.0
    Microsoft SQL Server 2005 SP3
    All running on one box
    Application pools running under default Network Service account

I believe this will not be limited to just CRM – at least one other report online of it affecting WSS.

Update 1:
Already a lot of hits today – if this solution works for you, please post and let everyone know. Also summarise your setup so we can work out when this is happening ūüôā

Update 2:
Kudos to Richard (who has commented below) for discovering that Microsoft have now rushed out a KB article to explain the problem and propose a longer-term fix: In short, reinstall Windows 2003 SP2.

Debugging plug-ins in v4.0 (Updated)

(Updated 9th June 2009)

As you will know, the extensibility model for Microsoft CRM has changed in v4.0 and we now have a concept of plug-ins (instead of the callouts that were used in v3.0).

I’m not a particularly seasoned C# developer but having got a comfortable grasp of the language, I was struggling when it came to debugging my plug-in. I knew the general principles of debugging and thanks to the plug-in registration tool, could get my code to fire, but I couldn’t get it to debug. I can now and here’s what I did (note – no revelations here, I’m simply writing this for the benefit of other n00bs).

Please note, I still use Visual Studio 2005. I haven’t done this in any other version so there’s no point in me trying to write about it – please comment if you have and whether these steps differ.

  • So you’ve finished coding and are ready to deploy your assembly. Step one is to build your project via the Build… menu in VS.
  • Next you need to deploy your assembly to the development server.¬†You’ll need to use the Plugin Registration Tool to do this. I usually opt to¬†deploy to the database as this¬†avoids me having to deal with “file in use”¬†errors (see below).
  • In addition to deploying your assembly you must also place the debug symbols (.pdb file)¬† in¬† …\Program Files\Microsoft CRM\Server\bin\assembly. Once you’ve built your solution in Visual Studio, ensure that the latest copy of the .pdb file (look in your solution’s build directory) is copied to the aforementioned directory.¬† Every time you (re)build your ¬†assembly you must copy the revised pdb file across.
  • After copying the pdb file, you’ll need to restart IIS using the iisreset command from the¬†command prompt. ¬†This is required so that the symbols can be read in (this step is also necessary sometimes in order to avoid “file in use” errors if you choose to deploy your assembly dll to disk) .¬†¬†I usually add an iisreset command¬†into my Post-Build script in Visual Studio, along with an xcopy command, to move the pdb file to the correct location after each build.
  • After running iisreset,¬†you need to effectively “kick start” the CRM thread¬†¬†by simply opening or refreshing any CRM page. This ensures that the w3wp process is available for the debugger to attach to.
  • The next step is to load your solution file up on the server. This of course requires Visual Studio to be installed on the development server. There may be alternatives to this approach (perhaps remote debugging or a test harness – see below) but I haven’t tried them.
  • With your solution open on the server, select Debug > Attach to Process and then select the w3wp.exe process from the the list. You may need to place a check in the “Show Processes from all users” and “Show processes in all sessions” in order to see w3wp.exe.
  • If you haven’t already done so, add some breakpoints to your code in VS by moving the cursor to the code you wish to break on and pressing [F9]. A red dot should appear in the margin.
  • Finally, go to CRM and do whatever is required (as per your plug-in registration) to fire your plug-in (i.e. create/delete/update an appropriate¬†record)
  • The code should fire and reach your breakpoint in Visual Studio. You can step through the code a line at a time by press [F11] to advance to the next statement.

You might also be interested to hear that Akezyt Janedittakarn wrote on the MSCRM Team Blog about steps to aid the debug process using a test harness 

I’ve just found this article at on how to debug CRM plug-ins remotely.