Premier Field Engineering Developer Blog

Windows Store Line-of-Business App Deployment via Windows Intune

Premier Field Engineers — Thu, 13 Jun 2013 13:17:00 GMT

Summary: Did you realize there are other options for deployment of your Windows Store Application in your Enterprise other than hosting it on a share or deploying via the Windows Store? Check out this video where Robert Evans talks to Mark Williams, a Microsoft Program Manager in the Enterprise Client Management Team, and learns all the details on how this is accomplished via Windows Intune, a great solution for deployment and management of your Windows Store Line-of-Business Applications. Enjoy!

We are joined by a special guest Mark Williams, a Microsoft Program Manager in the Enterprise Client Management team whom has worked on Windows Intune since its inception. Windows Intune is a cloud-based PC and mobile device management service. The service can be used as a “standalone” service (managed through its own administrative console) or through tight integration with System Center Configuration Manager. The presentation and demos will have a particular focus on the how Windows 8 Line-of-Business apps can be made available to end users on Windows 8 devices without needing to publish these internal business apps to the Windows Store nor host them on a share within your intranet. The Windows Intune Company Portal app will be used to view and install such apps, from the perspective of the end user.

Article written by Robert Evans and Christophe Nasarre.

How to Avoid WinRT Activation Pitfalls

Premier Field Engineers — Sun, 19 May 2013 20:13:00 GMT

Summary: If you're trying to get your Windows Store App published in the Windows Store and running into application submission failures, check out the great insight provided by Christophe Nasarre (a Microsoft Premier Field Engineer). In this article he walks us through application startup issues and how (and when) to use extended splash screens to get around these, along with other valuable nuggets. As well, he’s provided the following video to walk you through all of the details. Watch the video, read the post, and start making money with your apps!

Windows 8 offers new ways for a user to activate a Windows Store Application; from tapping its tile in the Start Screen, to starting a Search query or even picking it as a Share target. Each time, the application is supposed to start quickly and with a consistent set of data: these requirements are pitfalls you need to avoid in your code.

Application startup and extended splash screen

During our first episode, Robert Evans mentioned that the number #3 cause of Windows Store Application submission failure is due to performance problems. One of the issues that would make your App rejected is if it does not display a windows five second after the user starts it.

This scenario is checked by the Windows Application Certification Toolkit. As a reminder, it is mandatory that you run this tool before submitting your Application or an update to the Store for validation. You can easily run this tool on your application by right-clicking your project in Visual Studio and select Store | Create App Packages. Then, select No in the first dialog because you don’t want to directly publish to the Store

Next, you select a Release configuration

And click the Create button to let Visual Studio generate the package. After this final step, click the Launch Windows App Certification Kit button

and leave your machine alone while the lengthy checks are executed.

In case of error, the report generated by the tool is not very explicit to pin point this specific issue. You need to navigate to the Performance Launch section to find the corresponding failure

FAILED

Performance launch

· Error Found: The performance launch test collected the following results:.

Application Error: Application Launch was not detected for application App. This could be because your application failed to launch correctly. Please consider re-running the test and avoid interacting with the application while tests are running.

When you read “This could be because your application failed to launch correctly“ it means that your application failed to display a window in less than five seconds after it was activated.

In a perfect world, this five seconds restriction might not be a problem to solve. However, most of the applications need to download part of their content from the Internet and you never know how bad the connection will be. And during that processing, you don’t want to display an empty main page!

So, the question is: how to fulfill the five second requirement so my application will be successfully validated by the Windows Store while providing a compelling user experience? Well… just display a waiting screen before navigating to your main page once the data has been fetched! This special screen is called an extended splash screen.

An implementation is available in the Windows SDK web site and my updated version can be found here. This code sample leverage the first background that Windows displays for us when the application gets started. This is built based on the splash screen asset that we define in the manifest file. It is centered in the screen on a background filled with the color also set in the manifest.

In addition to showing an animated progress ring, the ExtendedSplash class is a Grid UI element that positions the splash bitmap asset on the screen. This cannot be done at compile time because it depends on the screen size of the device where the application will run. Hopefully, Windows provides this piece of information in the LaunchedActivatedEventArgs passed to the OnLaunched application override: its ImageLocation property is the rectangle where the bitmap has been displayed on the screen by Windows.

When the lengthy initialization is over, the code simply creates a frame and uses it to navigate to its main page. Et voila!

Before going to the next pitfall, I would like to be clear: an extended splash screen is really the last solution to choose because the more the end user will wait in front of such a waiting page, the worse the experience will be. It is recommended to bring as much content as possible in the application package submitted to the Store to avoid this type of slow start. And if this is not enough, you can think of downloading content while the application is running or with background tasks and save it locally to speed up the next launch of the application. Don’t forget: your application should be fast and fluid to be successful!

Supporting multiple activations with VS templates

Visual Studio provides templates for Windows Store Apps skeleton projects. Templates for implementing main contracts are also available with the Add New Item command on a project.

In addition to updating the project manifest file and creating new pages for the UI, new override methods are added to the application class. Each one is called when each different activation mechanism is triggered as shown in the following list:

Tile tapped in the Start Screen: OnLaunched
Chosen for a Search query: OnSearchActivated
Selected as a Share target: OnShareTargetActivated

The code generated by Visual Studio for the OnSearchedActivated override does its best to handle most of the activation scenario:

It checks that a frame has not been created already (i.e. the application is already running when the search is triggered)
If the frame is not created, a new one is instantiated
Then, the frame navigates to the SearchResult page before being displayed on the screen

This sounds good except for the scenario #2: the application was not running, so the main page was not navigated to by the frame and only the SearchResult page will be available to the user: no BACK button. Even worse, the internal object model of the application that is defined in the SampleDataSource class was not initialized!

To solve this problem, you just have to copy the code in the OnLaunched override that navigate to the main page: it will add it into the page stack of the frame (making visible the BACK button in the SearchResult page) and the SampleDataSource will be setup (done in the LoadState override of the GroupedItemsPage when navigating to the main page) as shown in the following code excerpt:

protectedasyncoverridevoid OnSearchActivated(Windows.ApplicationModel.Activation.SearchActivatedEventArgsargs)

{

   ...

    if (frame == null)

   {

        ...

        // WSA-CN: don't forget to add the main page to the frame stack

        //         before navigating to the Search result page

        //         --> that way, the BACK button will be visible

        //             in the Search result page

        //         as a side effect, this navigation will initialize

        //         the internal object model stored in the SampleDataSource class

        if (!frame.Navigate(typeof(GroupedItemsPage), "AllGroups"))

        {

            thrownewException("Failed to create initial page");

        }

   }

   ...

}

Resources

Top 5 Reasons Your Windows Store App Fails Store Certification

Premier Field Engineers — Mon, 06 May 2013 13:50:00 GMT

Summary: Whether you're trying to get your Windows Store App certified in the Windows Store and running into blockers, or simply writing a new app for Windows 8 that you expect to publish via the Windows Store, check out the great insight provided by Robert Evans and Christophe Nasarre (two Microsoft Premier Field Engineers) in this article on the primary culprits you might run into when it comes to the certification process. They are technical leads for Windows Store App Labs and they provide a multitude of tips and pointers to some great resources. If that’s not enough, they also have the following video to walk you through some of the details. Watch the video, read the post, be informed!

When submitting your app to the Windows Store (http://www.windowsstore.com) you may encounter issues with Store Certification. These are the top 5 most common Store Certification blockers that we’ve seen in our Windows Store App Labs – and how you can fix them. Let’s count-down in reverse order:

Number 5: Your App Should be Fully Functional

Certification requirement 1.2: “App must be fully functional” (also similar failure is related to certification requirement 3.2 “Your app must not stop responding, end unexpectedly, or contain programming errors”).

If you are failing on this certification requirement there are some things you should check:

Have you tested your App Snapped? Are there overlapping icons in your app bar while snapped?

Does the charms menu cover up any critical commands?

If you’ve declared your app as supporting portrait and landscape – does it?

Does your submitted description talk about features you haven’t implemented yet? Does your app crash at any point?

If the app plays background audio does it implement play, pause, and play/pause events to enable users to control audio playback?

If your app has “login” functionality did you create a test user account and provide the username/password in the “Notes to Testers” field when you submit your application?

Does the app work on all the architectures such as ARM that you checked off and claim to support when you submitted your app?

Have you run the Windows App Cert Kit against your app – and from an ARM device such as Surface?

Number 4: Localize Appropriately

Certification requirement 6.5: “You must localize your app for all languages that it supports.”

This is different than specifying Markets. Your supported language may differ from the Markets, and Markets are specified when submitting your app under “Selling Details.” For example, if you open Package.apppxmanifest and under your <Resources> specify <Resource Language="x-generate" /> then Visual Studio will automatically add the languages your app supports based on the discovered resources when generating your final manifest. The important thing with regards to certification is that you support at least one of the allowed 37 certification languages. You may support any number of the 66 total allowed languages, but at least one language must be one of the allowed certification languages for testing purposes. Be sure that all of your images are also localized – if you have any images that contain text they should be localized.

Number 3: Performance

Certification requirement 3.8: “Your app must meet the basic performance criteria on a low-power computer - the app must launch in 5 seconds or less and the app must suspend in 2 seconds or less.”

The Runtime broker suspends all threads of any Windows Store App that is not in the forefront. If your app takes more than the allotted time to save state while suspending or takes too long while loading then the your app will be terminated. Typically this failure is uncovered by testing with the latest version of the Windows App Cert Kit which does automated tests of this. Failing on this requirement results in a technical compliance failure. In some cases people run the Windows App Cert Kit on their developer machine but when they submit to the store they still fail with this issue. That is why we recommend running the Windows App Cert Kit against your app on different hardware – including on an ARM device such as Surface.

Then the question is what are you doing in your app when you are loading and when you are suspending? If you are talking to webservices perhaps it works on your local machine but not when you upload as performance may vary based on different network capability. You should avoid any long operations when loading and when suspending and save state only locally. LocalSettings is a keyvalue pair that can be used that saves locally. RoamingSettings saves locally first and then synchs at a later date so that too is a great way to save data – and it is easy to change the default backing store of the SuspensionManager to RoamingSettings (see http://aka.ms/vrrplb).

If you find your initial loading is taking a long time due to heavy operations such as xml serialization then check out the MSDN Splashcreen Sample. They load the app and then create a fake splashscreen while they continue heavy loading operations – that’s one way to get around the time limitations.

Another common issue related to performance is when navigating pages within your app – you should only use simple types for your navigation parameters – such as Strings or Ints.

Number 2: Primary Experiences Stay Within The App

Certification requirement 2.4: “The primary experiences your app provides must take place within the app.”

This was a very common failure reason particularly in the first wave of Windows Store Apps and it is still common today. You should not redirect the user to the web browser to complete one of your primary scenarios. In our labs we recommend developers document their five primary scenarios for testing and include them in their tester notes with each step and a “scenario complete” at the end.

It’s okay to redirect the user to the browser or even embedded browser for other scenarios in your app such as submitting help requests or tutorials and such – but it’s not okay for your primary scenarios. You should not take them out to a browser nor should you use an embedded browser.

The reason is simple – if you are using a browser to complete your primary scenario – then it is arguable that your app should be a website and not an app.

Number 1: Privacy-Related Requirements

Drum roll please… the number one top failure reason for Windows Store Certification is…

Certification requirement 4.1: “Your app must comply with the following privacy-related requirements”

Why do so many people fail on this? By default in Visual Studio, Windows Store App templates have the Internet (Client) capability declared. When this is declared – even if you aren’t using it – you must have a Privacy Statement and it must be available from the Settings Flyout. That Privacy Statement can be a link to your online Privacy Statement or another page within your app that lists the Privacy Statement. If you are not using the network you can simply disable that capability to avoid this requirement. Otherwise it is easy enough to add a settings flyout. There are examples on MSDN or see Tim Heuer’s excellent free Callisto controls also available as a Nuget package.

In that similar category of failure reasons – if you are selling your app – you must also have a help and support section. There are three acceptable help and support options. A telephone, an email address (and they will test if it is a working address) or a webform. The help and support can be a separate link from your Settings flyout or it can be within your About section (also linked in your Settings flyout).

Finally…

If you’ve followed these pointers and you’ve checked the Windows Store Apps Forums and you are still blocked on Store Certification – please don’t sit there in frustration depriving the world of your amazing app!

Please either visit one of our free Windows Store App Labs (www.windowsstore.com/applabs) or follow the instructions below to get fast assistance. There’s even a “chat” option!

1)    Visit the URL: http://aka.ms/storesupport

2)    Towards the bottom of the page, there is a link that says “…contact us immediately.”

3)    Click that link and then it will ask you to choose the support type. To reach the App Certification team choose the following:

Problem Type: “App Submission and Certification”

Category: “Submitting an app”

Once you do that chose an option for support such as “Request a Call”

Windows Store App Development, with Christophe

Premier Field Engineers — Fri, 05 Apr 2013 01:21:34 GMT

Christophe Nasarre-Soulier is a development-focused PFE I’ve worked via the Windows Store App Labs program.

As part of that program, we provide design and development assistance to Windows Store App developers across the world, and gained a lot of exposure to common questions, issues, and techniques.

Christophe’s been busy blogging some of his learnings on Windows Store Apps – including (naughty!) testing-only features that are fun to play with in local development environments but that won’t pass Store certification requirements – and has a veritable smorgasbord of posts for you to consume.

First up, his series on inter-process communication with Windows Store Apps:

Since the pre-release of Windows 8 at the Microsoft BUILD conference in 2011, I’ve been investigating the different ways for a Windows Store App (WSA in the rest of the post) to interact with either other WSAs or Desktop Apps (DA in the rest of the post). Unlike .NET that was built from the beginning with interoperability in mind, WinRT is another beast.

A Microsoft collegue has been working on a WSA that makes it simple to deploy and launch applications in an enterprise environment (visit http://companystore.codeplex.com/ for more details). However, some actions are not allowed from a WSA such as looking for installed WSAs and launch them. This was a great opportunity to turn my research into real code. I’m sharing the outcome in a few blog posts starting with this one.

The first post (linked above) covers the basics of possible interaction mechanisms between Windows Store apps (file associations and protocol handlers), and it’s a quick, helpful read.

The second post delves deeply into using file associations to allow app activation outside the bounds of a Windows Store App into a desktop app – with the requisite warning that you can’t do this in a Store-published app:

WARNING: all these techniques are violating the point 3.1 from the Windows Store Requirements that states: “Your app may only depend on software listed in the Windows Store“. Therefore, you should not use them for a WSA that you plan to publish into the Windows Store because it will be rejected.

It’s a fascinating look into the internals of how file association activation works.

Christophe’s back-catalogue covers lots of other WinRT-related goodness, from Windows Store checklists to make it easier to make great Windows Store apps, to a tool that identifies BCL classes available vs excluded from WinRT and the .Net Framework 4.5. Enjoy!

Posted by Tristan Kington, MSPFE Editor that just got to use the word “smorgasbord” in a serious context

Taming XML query performance using persisted computed columns

Premier Field Engineers — Tue, 26 Mar 2013 09:58:55 GMT

Storing data in XML format has presented a conundrum to SQL developers from time to time. While storing it is easy, how does one efficiently extract those pieces of data which are needed from the XML field?

My friend and PFE colleague from Dubai, Batuhan Yildiz, had faced this situation recently. He shares his experiences on the performance impact of retrieving specific data from the XML field, and presents an interesting way of solving the issue by using persisted computed columns. Read the details at his blog here!

Linked content authored by Batuhan Yildiz; posted by Arvind Shyamsundar

The case of the broken AppFabric

Premier Field Engineers — Fri, 22 Mar 2013 09:36:44 GMT

This article has been contributed by Vasco Preto, a Premier Field Engineer with Microsoft Portugal. Vasco is no stranger to MSPFE, having previously contributed a very interesting case study on our TechNet blog. This time he shares a captivating walkthrough on how to troubleshoot AppFabric caching services.

I’ve been recently involved in troubleshooting a production problem reported by a customer which revolved around a generic error that was preventing client applications from successfully establishing a connection to the AppFabric – Caching Services layer. Here’s a quick recap of what the exact symptoms were and the analysis and diagnostic that resulted from the troubleshooting effort.

Problem description

The client presented a specific case where a set of recently deployed client applications were unable to connect to the AppFabric – Caching Services layer. This specific error was generating the following message (extracted from the event logging system).

{Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode<ERRCA0017>:SubStatus<ES0006>:There is a temporary failure. Please retry later. (One or more specified Cache servers are unavailable, which could be caused by busy network or servers. Ensure that security permission has been granted for this client account on the cluster and that the AppFabric Caching Service is allowed through the firewall on all cache hosts. Retry later.)

Furthermore, the client stated that this error was only affecting a subset of client applications and these specific client applications had functioned correctly in the past and, supposedly, they had not been subjected to any change recently.

Analysis

Step 1: Check for known issues

Considering the starting point, which was little more than a fairly generic message, I did a quick search through existing KB articles in an attempt to clarify which conditions could actually lead to this type of error. Unfortunately, this quick research did not produce a more defined and limited scope to investigate, as there are many different conditions that can lead to problems which are reported through error code ERRCA0017 and sub-status code ES0006.

Step 2: Check if the AppFabric cluster is running

Considering that the client was describing the problem as a connection error between client applications and AppFabric server, I started off my direct troubleshooting effort by verifying that the AppFabric cluster was in fact up and running. Using some administrative PowerShell commands I concluded that the AppFabric server was in fact working properly (commands used include Get-CacheClusterHealth, Get-Cache and Get-CacheStatistics).

Afterwards, I verified if I could in fact establish a TCP connection between client and server machines through the AppFabric port, which is port 22233. By using a simple telnet client utility I did in fact verify that the client application was able to connect to the server through port 22233. However, when that connection was established through AppFabric’s client libraries the previously showed error would appear.

Step 3: Gathering network traces

At this point, I was able to get a few network traces supplied by the customer’s operations team. As shown in the following image, which depicts the filtered frames that pertain to the action of establishing the AppFabric connection (filtered by client and server IP addresses), we can clearly see two things:

The initial TCP/IP handshake between client and server was correctly established.
A few frames after the handshake, the server reset the connection.

Step 4: Drilling down into the network trace

Continuing within the network trace, and following the TCP stream regarding these frames, I could drill down on a bit more information. As seen in the next image, the information contained within the network trace showed a few more interesting pieces of information:

Information regarding the client and its credentials.
Identification of the server to which the communication was being established.
References to authentication protocols.

Step 5: Checking which accounts have access to AppFabric

At this point, I discussed the situation with the customer and we both agreed that the problem seemed to be related with client credentials and inherent authentication process. Going back to the PowerShell administration console, we analyzed which accounts had been granted access to AppFabric. As shown in the next output, the existing configuration was apparently allowing a wide open access to all client credentials.

PS C:\Windows\system32> Get-CacheAllowedClientAccounts
EVERYONE
ANONYMOUS LOGON

Despite this configuration, I queried the customer about the exact credentials that the client was sending (which were also identifiable in the previously shown TCP stream – please note reference to local machine) and we concluded that the client application was using a local account. As such, the customer agreed to change the client credentials and the client application was reconfigured to use a domain account.

Step 6: AppFabric logging and ETW

Unfortunately this change did not fix the problem so we analyzed other available troubleshooting options and decided that we needed to get more logging data from AppFabric. By the way, this avenue has impact as it requires restarting the cache service, which implies temporarily restarting one of the cache cluster nodes, and hence temporarily affecting performance (other cache nodes are not directly affected, but regions within this node will ultimately need to be re-populated from ground up afterwards). After some debate, the client accepted this route and we performed two actions.

Firstly, we changed the logging level of the caching service by adding the following configuration elements to its configuration file (file DistributedCacheService.exe.config).

<system.diagnostics>
    <sources>
      <source name="System.ServiceModel"
              switchValue="Information, ActivityTracing"
              propagateActivity="true">
        <listeners>
          <add name="traceListener"
              type="System.Diagnostics.XmlWriterTraceListener"
              initializeData= "c:\Temp\DistributedCacheService.svclog" />
        </listeners>
      </source>
    </sources>
    <trace autoflush="true" />
</system.diagnostics>

Secondly, we activated ETW for AppFabric through the following command line:

tracelog.exe -start debugtrace -f "c:\Temp\cachedebugtrace.etl" -guid "c:\Windows\System32\AppFabric\Manifests\ProviderGUID.txt" -level 5 -cir 512

Step 7: Analyzing ETW

After acquiring the ETW log we transformed it into a CSV file through the command:

tracerpt "c:\Temp\cachedebugtrace.etl" -o "c:\Temp\cachedebugtrace.csv" -of CSV

And by analyzing its contents we were able to find some interesting information such as:

"Recoverable exception raised - ChannelID = 29180324 System.ServiceModel.ProtocolException: Stream Security is required at http://www.w3.org/2005/08/addressing/anonymous, but no security context was negotiated. This is likely caused by the remote endpoint missing a StreamSecurityBindingElement from its binding. at System.ServiceModel.Channels.ServerSessionPreambleConnectionReader.ServerFramingDuplexSessionChannel.SetupSecurityIfNecessary() at System.ServiceModel.Channels.ServerSessionPreambleConnectionReader.ServerFramingDuplexSessionChannel.OnOpen(TimeSpan timeout) at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout) at Microsoft.ApplicationServer.Caching.WcfServerChannel.Listen(IAsyncResult result)"

Interestingly, this message hints that there is something definitely wrong with the security context, but not necessarily implying problems with credentials. It also suggests that there are some issues with the underlying WCF transport that is used between client application and AppFabric server whenever the AppFabric API is used.

The error message is almost clear to the point that it identifies the lack of a required security context, which results in a binding error to an existing WCF endpoint. To confirm this we opened the log file (the svclog file generated by the changes introduced in the distributed cache service configuration file) which confirmed what had been established so far (as shown in the following picture).

In possession of all this information we went back to the configuration files of both client application and AppFabric server and concluded that there was indeed a mismatch, as the client configuration (contrary to what was defined in the server side configuration) was using None as the configuration value for both securityMode and protectionLevel (more information on these options can be found here.

Finally, the solution!

So, finally, to fix the problem we changed the securityMode to Transport and the protectionLevel to EncryptAndSign and, having matched client and server configuration attributes, the solution was finally up and running.

To wrap up, it is almost inevitable to report that, as it turns out, someone had, inadvertently, copied a configuration file from development environment to production, thinking that they were an exact match, without verifying that the security configuration elements were in fact distinct.

I guess this is another example that supports the prohibition of direct copying from development and quality environments into production environments, although a more clear error message from AppFabric would also be much appreciated .

Written by Vasco Preto; posted by MSPFE Editor Arvind Shyamsundar

More Efficiently Debug the Managed Heap Using SOS 4.5

Mario Hewardt — Wed, 13 Mar 2013 22:27:00 GMT

More often than not, when we investigate the managed heap using SOS we use the all powerful !DumpHeap command. It's an incredibly useful command to get in depth detail on what currently resides on the heap. Let's look at an example of the abbreviated output from !DumpHeap -stat: MT Count TotalSize...(read more)

Video series: .Net Debugging for the Production Environment

Premier Field Engineers — Wed, 30 Jan 2013 10:38:59 GMT

Brad Linscott is a very experienced Premier Field Engineer from the .Net development side of the house (Ed: who originally trained me in .Net Debugging techniques, oh, eight? years ago?) and he’s published a video series on .Net Debugging on Channel 9, which runs you from the basics to some quite advanced techniques in .Net debugging, as performed by the experts!

This series was created based off of a thread on the Channel 9 Site Feedback forum. Read the original post here. We heard what you wanted, so we created the first .NET Debugging Starter Kit series. With the help of Brad Linscott, Premier Field Engineer, this series will teach you how to use various tools, including the Debugging Tools for Windows package (windbg), to resolve your .NET application issues in a production and pre-production environment, including post-mortem analysis of dump files.

It’s a series of shortish videos (given the subject depth), which is nice and lunch-break friendly. Or you could replace your mandatory afternoon snooze with learnings!

Posted by Tristan Kington, MSPFE Editor, and a table as well.

Free Expert Advice for Building Your Windows 8 Apps. Windows Store App Labs!

Premier Field Engineers — Fri, 25 Jan 2013 15:59:00 GMT

Summary: Robert Evans, a Senior Microsoft Premier Field Engineer focused on development, informs us of some awesome resources for Windows 8 developers to get advice from experts and access to a myriad of Win8 devices. Take advantage of it if you can.

Windows Store App Labs (WSALs) are here! A place where you can access Windows 8 devices, get design help, and meet with Windows 8 Experts to make your app great! All for free!

Get technical guidance from Windows 8 Experts

Our Windows Store app developer experts are on-hand to help you get started, to test your app and offer any technical advice you need! We can help you with coding tips, debugging, and prepping your app to submit to the Windows Store.

Check out and test on the newest Windows 8 devices

Test your app on a variety of screen sizes, input methods, and chipsets with the latest Windows 8 devices including Windows RT tablets, Ultrabooks, All-in-Ones, and more. Designers will review your app mock-ups or your complete app and provide feedback on how you can improve your app’s layout, navigation, live tile, and other UI elements.

As you get started - check out 5 tips to help you get your app certified quickly, top 10 app secrets of success, Win8 Forms and more helpful information on our lab resources page.

All for free!

Space is limited. Please register for a lab in your location:

Country	City	Registration Link
Canada	Vancouver	https://applabs.msregistration.com/LabList.aspx?drop=52&userid=null#list
US	San Francisco/Santa Clara	https://applabs.msregistration.com/LabList.aspx?drop=139&userid=null#list
Canada	Toronto	https://applabs.msregistration.com/LabList.aspx?drop=40&userid=null#list
US	New York	https://applabs.msregistration.com/LabList.aspx?drop=140&userid=null#list
England	London	https://applabs.msregistration.com/LabList.aspx?drop=9&userid=null#list
France	Paris	https://applabs.msregistration.com/LabList.aspx?drop=13&userid=null#list
Belgium	Brussels	https://applabs.msregistration.com/LabList.aspx?drop=25&userid=null#list
Czech Republic	Prague	https://applabs.msregistration.com/LabList.aspx?drop=25&userid=null#list
Sweden	Kista	https://applabs.msregistration.com/LabList.aspx?drop=22&userid=null#list
Turkey	Istanbul	https://applabs.msregistration.com/LabList.aspx?drop=22&userid=null#list
India	Mumbai	https://applabs.msregistration.com/LabList.aspx?drop=22&userid=null#list
India	Bangalore	https://applabs.msregistration.com/LabList.aspx?drop=3&userid=null#list
China	Beijing	https://applabs.msregistration.com/LabList.aspx?drop=11&userid=null#list

Debugging STL containers using WinDbg

Premier Field Engineers — Tue, 15 Jan 2013 05:02:02 GMT

My good friend and colleague, Ambrose Wong, is a Principal PFE in Hong Kong. He has been debugging and troubleshooting production issues for over a decade now. More importantly, he mentors our customers to be their own hero and debug issues on their own.

One of the conversations we have with customers who are using WinDbg for the first time is obvious comparisons with Visual Studio, and how easy it is to ‘Watch’ things in VS.NET. The expression evaluation (a.k.a. Watch) capability in VS.NET is very easy to use, but what if you have to do that with WinDbg in a production environment?

While it may be easy to dump scalar values, how about when you are dealing with STL vector classes, such as vector<>? It may not be very apparent how to do that in WinDbg. Ambrose has started a series on how YOU can do that yourself – read the introduction and part 1 of his series. Highly recommended for WinDbg buffs!

BTW, if you have never heard about the Standard Template Library – STL – you can hear Stephan Lavavej (Mr. STL himself ) introduce it here.

Posted by Arvind Shyamsundar, MSPFE Editor