Luxury sports cars in costly Japan pile-up

Japanese police said some of the luxury vehicles were beyond repair

Continue reading the main story

Related Stories

• In pictures: Sports cars pile-up

A luxury sports car outing in Japan has ended in what may be one of the most expensive car crashes in history.

Eight Ferraris, three Mercedes-Benzes, a Lamborghini and two other vehicles were involved in the pile-up in the southern prefecture of Yamaguchi.

No-one was seriously hurt, but the road was closed for six hours after the accident.

Media reports estimate the damaged cars are worth at least 300m yen ($3.85m; £2.46m) in total.

The drivers were on an outing to the city of Hiroshima

The sports cars – driven in convoy by a group of automobile enthusiasts – were on their way to Hiroshima, reports Japanese newspaper The Asahi Shimbun.

Police say they believe the accident, which took place on Sunday, happened when the driver of one of the Ferraris tried to change lanes and hit the crash barrier.

“A group of cars was doing 140-160km/h (85-100mph),” an unidentified eyewitness told Japanese broadcaster TBS.

“One of them spun and they all ended up in this great mess.”

Ten people received minor injuries in the crash, police said.

They said some of the vehicles were beyond repair.

“I’ve never seen such a thing,” highway patrol lieutenant Eiichiro Kamitani told AFP news agency. “Ferraris rarely travel in such large numbers.”

Ouch!

There is lots of advice on the web regarding debugging CRM workflows and plugins; however I recently stumbled upon this article which has a few neat tricks in it for saving time during the “debug cycle”.

Debugging CRM involves a lot of steps.  These steps take time.  You end up waiting forever from the time you make a code change to the time that you are debugging again.  I wanted to share a couple things I have learned about debugging that have saved me a great deal of time.

Time Wasters:

• Starting and stopping IIS and the async service
• Deploying your new assembly
• Attaching to processes
• Getting back to debugging after making a small code change

Let’s get started…

Project Setup
I’m using a Virtual PC (actually VMWare Fusion on My MAC, but that’s another story) running Windows 2008 R2, SQL 2008 R2 and Microsoft CRm 4.0; I also have Microsoft Visual Studio 2008 installed.

Note:  I stay away from remote debugging when possible as it requires specific security privileges on the CRM server and you will affect users that are trying to access the system. I will post about this at a later date.

To make life easier I set the build path for my workflow project to the CRM assembly folder. On my machine it is C:\Program Files\Microsoft Dynamics CRM\server\bin\assembly\.  It varies from installation to installation; depends were you installed CRM!  Building to this location allows us to register the plugin to disk and make code changes quickly without having to move files around or re-register anything. Nice tip – hey?

Register Plugin
Open the registration tool and register your plugin or workflow.  Be sure to register the plugin to disk.

Note:  When you move to production I recommend registering to the database, but registering to disk works great for debugging.

If your note sure what the “registration tool” is then you are jumping the gun and probably need to refer to the CRM SDK or wait for an up coming post form me on the registration tool!

Attaching to Processes
Now that you have the plugin registered, you are ready to start debugging.  You need to attach to W3WP.exe to attach to plugins since they run within IIS.  To attach to workflows you need to attach to the CRM async service which is Crmasyncservice.exe.

Select w3wp.exe and Crmasyncservice.exe and click “Attach.”

To save time with this process you can use a cool trick from Janne Mattila.  You leverage VS macros to attach to the processes by using a shortcut key.

Something like this:

Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports System.Diagnostics

Public Module AttachHelper
‘ This subroutine attaches to w3wp.exe:
Sub Attach()
Dim attached As Boolean = False
Dim proc As EnvDTE.Process

For Each proc In DTE.Debugger.LocalProcesses
If (Right(proc.Name, = “w3wp.exe”) Then
proc.Attach()
attached = True
End If
Next

If attached = False Then
MsgBox(“Couldn’t find w3wp.exe”)
End If

attached = False
For Each proc In DTE.Debugger.LocalProcesses
If (Right(proc.Name, 19) = “CrmAsyncService.exe”) Then
proc.Attach()
attached = True
End If
Next
If attached = False Then
MsgBox(“Couldn’t find crmasyncservice.exe”)
End If
End Sub
End Module

This means you can now very quickly write code and start a debug session which is attached to the correct processes straight from a  short cut key and because you are compiling into the CRM assembly folder you don’t need to copy your *.pdb file around.

But… there is a small got ya

After you have done this and you stop your debug session, make a code change and start trying to debug again you will receive a compiler error trying to build. This is because you are trying to build to a file location that is already locked by the async service and/or IIS.

To get around this create a batch file and run it every time you want to rebuild.  Includes the following:

iisreset
net stop MSCRMAsyncService
net start MSCRMAsyncService
“C:\Program Files\Internet Explorer\iexplore.exe” http://v-mat-sp:5555

This script restarts IIS to unlock w3wp.exe.  Then, it restarts the async service.  Lastly, we reopen the CRM website in IE, so IIS will re-spawn itself.  Otherwise, when you try to attach to processes it won’t be able to find w3wp.exe.

Credit: Andrew Zimmer