Tuesday, 23 September 2014

Windows Azure Storage Emulator failed to install


Windows Azure Storage Emulator failed to install

When attempting to install a new version of the Azure Storage Emulator either as a separate installation package or automatically as part of an Azure SDK update, you may run into an error message which states the storage emulator has failed to install. This can occur using the Web Platform Installer (WebPI), NuGet Package Manager or when performing the install manually.

Below is the message received using the WebPI.

 




Storage Emulator Background  (optional reading)

The windows azure storage emulator executable lives under the Microsoft SDKs directory as shown below:




Configuration

If we take a quick look inside the WAStorageEmulator.exe.config file we can see each of the storage services pointing to local service endpoints.

<StorageEmulatorConfig>
    <services>
      <service name="Blob" url="http://127.0.0.1:10000/"/>
      <service name="Queue" url="http://127.0.0.1:10001/"/>
      <service name="Table" url="http://127.0.0.1:10002/"/>
    </services>  

Database

By default, the storage emulator uses Sql Server Express with the LocalDB execution mode to store it's data for each of the storage services.

This configuration can be seen by looking at the DevelopmentStorage config file

<?xml version="1.0"?>
<DevelopmentStorage xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2009-03-18">
  <SQLInstance>(localdb)\v11.0</SQLInstance>
  <PageBlobRoot>C:\Users\Carl\AppData\Local\DevelopmentStorage\PageBlobRoot</PageBlobRoot>
  <BlockBlobRoot>C:\Users\Carl\AppData\Local\DevelopmentStorage\BlockBlobRoot</BlockBlobRoot>
  <LogPath>C:\Users\Carl\AppData\Local\DevelopmentStorage\Logs</LogPath>
  <LoggingEnabled>false</LoggingEnabled>
</DevelopmentStorage>

which can be found at at the location shown below:



When the development storage emulator starts for the first time it creates the v11.0 database in LocalDB. This can be verified from the command line as shown below:



If you want to choose another instance of SQL instead of LocalDB, you would need to change the <SQLInstance>**</SQLInstance> property accordingly as shown in the configuration snippet above.


The database files for the storage emulator are located in the logged in user root directory


The format of the database file name is WAStorageEmulatorDb<Version of storage SDK>.mdf
So the version of the azure storage emulator currently installed is 3.3 as shown above.

There will be a database per version of the SDK installed in this directory.

SQL Server Express 'LocalDB' Background (optional reading) 

Microsoft SQL Server express allows you to take advantage of the same powerful database engine in a version tailored for redistribution and embedding. SQL Server Express includes 10GB of storage per database, easy backup and restore functionality, and compatibility with all editions of SQL Server and Microsoft Azure SQL Database.

LocalDB is a special execution mode of SQL Server Express which runs under the users security context, targeted at developers.  



SQL Server Express LocalDB instances are managed by using the SqlLocalDB.exe utility. LocalDB can be used to work with SQL Server databases. System database files for a database are stored in the user's local AppData folder.

Diagnosis



Inspecting the install logs gives us an indication although subtle as to what is going wrong with the install. (cut down for brevity)

  1. === Logging started: 06-Apr-14  0:02:16 ===
  2. Action start 0:02:16: INSTALL.
  3. Action start 0:02:16: AppSearch.
  4. Action ended 0:02:16: AppSearch. Return value 1.
  5. ...
  6. Action start 0:02:16: InstallFinalize.
  7. CAQuietExec:  Windows Azure Storage Emulator 3.0.0.0 command line tool
  8. CAQuietExec:  Error: No available SQL Instance was found.
  9. CAQuietExec:  Error 0xfffffff6: Command line returned an error.
  10. CAQuietExec:  Error 0xfffffff6: CAQuietExec Failed
  11. CustomAction RunInitialize returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
  12. Action ended 0:02:16: InstallFinalize. Return value 3.
  13. Action ended 0:02:17: INSTALL. Return value 3.
  14. Property(S): UpgradeCode = {CF5CD495-AEDE-42DA-B7CF-A70D398D4E6A}
  15. Property(S): RunInitialize = "C:\Program Files (x86)\Microsoft SDKs\Windows Azure\Storage Emulator\WAStorageEmulator.exe" init -forcecreate -autodetect
  16. Property(S): DOTNET4FULL = 4.5.51641
  17. Property(S): LOCALDBINSTALLED = C:\Program Files (x86)\Microsoft SQL Server\110\LocalDB\Binn\SqlUserInstance.dll
  18. Property(S): SQLEXPRESSVERSION = 11.0.2100.60
  19. Property(S): TARGETDIR = J:\
  20. Property(S): StorageEmulatorMenuFolder = C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Windows Azure\Storage Emulator\
  21. Property(S): STORAGEEMUDIR = C:\Program Files (x86)\Microsoft SDKs\Windows Azure\Storage Emulator\
  22. Property(S): WixUIRMOption = UseRM
  23. Property(S): ALLUSERS = 1
  24. Property(S): ARPNOMODIFY = 1
  25. Property(S): REINSTALLMODE = amus
  26. Property(S): WindowsAzureMenuFolder = C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Windows Azure\
  27. Property(S): ProgramMenuFolder = C:\ProgramData\Microsoft\Windows\Start Menu\Programs\
  28. Property(S): WINDOWSAZUREDIR = C:\Program Files (x86)\Microsoft SDKs\Windows Azure\
  29. Property(S): MICROSOFTSDKSDIR = C:\Program Files (x86)\Microsoft SDKs\
  30. Property(S): ProgramFilesFolder = C:\Program Files (x86)\
  31. ...
  32. Property(S): ProductToBeRegistered = 1
  33. MSI (s) (6C:2C) [00:02:17:017]: Product: Windows Azure Storage Emulator - v3.0 -- Installation failed.
  34. MSI (s) (6C:2C) [00:02:17:017]: Windows Installer installed the product. Product Name: Windows Azure Storage Emulator - v3.0. Product Version: 3.0.6848.39. Product Language: 1033. Manufacturer: Microsoft Corporation. Installation success or error status: 1603.
  35. === Logging stopped: 06-Apr-14  0:02:17 === 

The error message at first may appear confusing as you most likely do have an available SQL instance. However digging a little deeper into what the installer is attempting to do will help resolve the issue.

Looking back at the error log may have left you confused as you may well have verified that a LocalDB instance does indeed exist.

Taking a look at the 'application' event log however reveals more detail.

Log Name:      Application
Source:        SQLLocalDB 11.0
Date:          
Event ID:      267
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      
Description:
LocalDB instance is corrupted. See the Windows Application event log for error details.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="SQLLocalDB 11.0" />
    <EventID Qualifiers="35269">267</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2014-05-05T16:44:32.000000000Z" />
    <EventRecordID>74923</EventRecordID>
    <Channel>Application</Channel>
    <Computer></Computer>
    <Security />
  </System>
  <EventData>
  </EventData>
</Event>


Log Name:      Application
Source:        SQLLocalDB 11.0
Date:          AM
Event ID:      261
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      
Description:
Cannot access LocalDB instance folder: %%LOCALAPPDATA%%\Microsoft\Microsoft SQL Server Local DB\Instances\<instance name>.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="SQLLocalDB 11.0" />
    <EventID Qualifiers="35269">261</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2014-05-05T16:44:32.000000000Z" />
    <EventRecordID>74922</EventRecordID>
    <Channel>Application</Channel>
    <Computer></Computer>
    <Security />
  </System>
  <EventData>
  </EventData>
</Event>

Here we see a more granular level of explanation, informing that the LocalDB instance is corrupt.

When we upgrade versions of the Storage Emulator it is most likely that the database has undergone some new enhancements, as a result we need to ensure the database gets updated regardless of it's prior existence.

The Storage Emulator database, we mentioned earlier, only gets created on first run of the storage emulator if it doesn't already exist. If we look more closely at the command line tool switches available for the 'Init' command we observe the -forcreate option. This forces the creation of the SQL database, even if it already exists. 


As our error is at the instance level, the storage emulator command line tool using the -forcreate option won't buy us anything. However if our error message was related to the actual database it would certainly come into play.

In this case we can go direct to the database instance, stop it, delete it and re-create it, including the removal of any storage emulator databases that may have been partially created along the way.

Firstly stop the LocalDB instance from the command line by issuing the stop command as shown below:



Then proceed to issue the  delete command: sqllocaldb delete v11.0 

It is possible that the WAStorageEmulatorDb* database has been created from a previous attempt of the current upgrade you are trying to undertake. In this case at this point issues a command to delete the storage emulator database from the location shown earlier:
delete C:\Users\<Your user account>\WAStorageEmulatorDb*.* 

Proceed to re-create the LocalDB instance by issuing the following command: sqllocaldb create v11.0
After performing the steps outlined, we can re-run the upgrade and get the result we expected first time round.


Quick Reference

  • WAStorageEmulator [/start] [/stop] [/status] [/clear] [/init] [/help]

Useful Links



Conclusion

When experiencing issues upgrading the storage emulator, the install logs, event log and some understanding of what the storage emulator relies on to run, will help to problem solve installation issues. In our case it boiled down to a corrupt LocalDB instance which needed a nudge to re create.

We come to expect our upgrade experience to work almost flawlessly these days but it is always worth bearing in mind that an install is just a set of code steps written by someone like you or me using libraries with potential bugs just waiting to crop up, even with Test Driven Development (TDD), Behavior Driven Development (BDD), Integration and smarter software release cycles. 

Friday, 7 February 2014

Remote debugging Windows Azure Cloud Services from Visual Studio 2013

When your cloud services have been deployed and things are maybe not going quite as you expected, the first thing you may turn to is diagnostics. I recently ran into a scenario where using a Dev-Ops cloud logging service which was normally full of logs and graphical richness, decided to have it's own cloud moment and stop logging for a downtime period. This was compounded by issues that had arisen with a deployed service and understanding what was behaving unexpectedly was crucial, especially as all Integration, Smoke and Black Box tests as well as the local environment was working fine. I still had my trusty native Azure Diagnostics and Trace information inside table storage and text files but i needed more. In no time at all i was stepping through my code in the cloud as if it was running locally, well almost.

One of the nice features added to the Azure SDK 2.2 is remote debugging support for Windows Cloud Services. What makes it especially appealing is the ease at which you can debug Web and Worker roles, deployed to Azure using Visual Studio and just how simple it is to setup, which if you attempted in earlier releases of the SDK, you will appreciate.

Remote Debugging Walkthrough

Prerequisites



1: Create a Cloud Service


Feel free to skip this section if you are familiar with the process and want to jump to the good stuff.



Select a Web Role and Worker Role


Select Web API as the ASP.Net project web model



Having clicked 'OK' you will now have a cloud service project with two roles. Place your breakpoints in the desired locations, one in the worker and the other in the web controller as shown. Even though we haven't yet attached the debugger, it shows our intent for the next steps.





2: Setup Publish Settings


Now we have our boilerplate project, it's time to publish.
Select 'publish' from the cloud project as shown.



Either select 'Sign In' or if the pop up window appears in the next screen shot appears use that. either way enter your credentials you gained from creating your Azure account in the portal.




Once logged in, either create a new Cloud Service by selecting 'Create New' from the Cloud Service dropdown as shown below.


OR, select an existing Cloud Service if you created one previously as shown.
The important step at this point is to select 'Debug' as the Build Configuration as shown.



Select 'Enable Remote Debugging for all roles' as shown.



3: Publish


We are now ready to publish. Ensure the Remote Debugger is set to 'Enabled' as shown and select publish.



The progress of the deployment is shown in the Azure activity log as shown.



Once complete, the staging link will change to a deployment link as shown.



4: Attach to the debugger


Once the roles have initialized and started, you will be able to see your role instances in Server Explorer as shown.

Right click on an instance and select 'Attach Debugger'.


Click on the link in the Azure activity log shown previously to open your web role.
The web site runs in Azure as shown below.


Ensure your breakpoint is set in the controller and navigate to the API endpoint as shown below.


Your breakpoint is hit, in your local Visual Studio instance for your deployed role.



Additional Reading - How does it all hang together

When you turn on remote debugging, it packages Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) as well as supporting components and deploys them to each virtual machine selected.


Orchestrating the process are two components, the Connector and Forwarder. 

Connector

The Connector  is a web service which establishes a secure tunnel between Visual Studio and the Forwarder


Forwarder

The Forwarder forwards commands in the form of requests to msvsmon.


The following diagram taken from MSDN illustrates the communication between Visual Studio, the Connector, Forwarder and msvsmon.





The configuration of the component endpoints is added to the ServiceDefinition.csdef during the package process. Of particular note are the port ranges used by each component as shown below.



Note - It may be possible to incur conflicts if other applications or services use the same port numbers. 


References



Visual Studio 2012 Support

Remote Debugging Windows Azure Cloud Services with Visual Studio 2012


Conclusion

This has been a big boost to deployment productivity and fault finding recently and it's certainly much easier than it was before to configure and get going. Happy debugging those cloud deployments!