开启诊断
对于我们来说，和诊断有关的大多数工作都已经完成了。但是一定要记住，我们必须要把“sharedListener”添加到 “AzureLocalStorage”中。要完成这个工作，只需在“WCF Web Role”的“Web.Config”文件中交换一下被注释掉的“system.diagnostics”节点就可以了，就是这么简单。
除此之外，你还必须把下面这行代码添加到“WebRole.cs”文件中：
DiagnosticMonitor.Start(CloudStorageAccount.DevelopmentStorageAccount, diagnosticConfig);
在使用SDK 1.3把日志迁移到BlobStorage的过程中，我遇到了一个问题。这个问题和作为SVCLog被创建的文件上的可用的权限有关。针对这个问题，有两种解决方案。首先，你可以模仿RobinDotNet（具体可以参考：http://robindotnet.wordpress.com/2011/02/16/azure-toolssdk-1-3-and-iis-logging/ ——我会在以后的文章中讲述具体应该怎么做的）的做法，或者，你也可以在“ServiceDefinition.csdef”中彻底地删 除<Sites>节点，这意味着它将不再作为一个完整的IIS来运行。我选择了第一种方法，在本文中我只是简单地总结了一下，关于我是如何让 它正常工作的，以后我会单独写一篇文章来说明的。现在，如果你无法解决这个SDK 1.3中的已知问题，你可以通过浏览它们的文件路径（使用Development Emulator）直接访问这些文件，或者你也可以使用远程桌面来访问云中的日志。
如果你对立即可以使用的WCF的跟踪日志比较好奇，你可以打开附属的项目，看看它是如何为你工作的——你可以把注意力放在 “FixDiagFolderAccess.ps1”这个powershell脚本上。它为这个文件夹创建了一些访问控制表，更重要的是，它会为这个文件 创建一个NULL或者完全为空的占位符（我们最后会重写这个文件）。
它可以给你提供SVCLog的定义，其中包括了绑定和异常的所有细节。在这里，你可以找到“DivideByZeroException”，然后开始诊断这个问题。
这个文件首先会出现在硬盘上：
片刻之后（注意，在这篇博文中，这个时间没有什么暗示！），Windows Azure Diagnostics系统会把这个文件迁移到blob storage的WAD-TraceFiles容器中。
在此之后，这个日志可以被下载，用来检查错误。在这个例子中，我们可以向下滚动，直到找到和被0除有关的细节，然后我们会发现有一个红色高亮的行显示发生了一个异常。要想查看更多的细节，我们可以从服务端获取这个错误真正的堆栈跟踪信息。
这篇博文的源代码可以从如下地址下载：
http://assets.bareweb.eu/wp-content/uploads/2011/03/WCFBasic.zip