How to capture crash dump for Desktop Bridge Converted or UWP app

Here is the guide on how to capture crash dump for UWP and Desktop Bridge Converted Apps:

1. Install Windows SDK which includes Windows Debugger (by clicking Install SDK)

https://developer.microsoft.com/en-us/windows/downloads/sdk-archive

 

clip_image002

 

2. Only select Debugging Tools for Windows to finish install.

clip_image004

 

3. Open Powershell Command, run this command to get your application ID:

Get-appxpackage | select-string WPFUWP

For example, I go the result: WPFUWP_1.0.0.1_x86__s46g25shpckvj for my App WPFUWP.

4. Based on your app bit, open Command Window, use 32bit (x86) folder or 64bit (x64) folder of Windows Debugger, run this command (my wpfuwp is 32bit app, so I choose Debuggers\X86) to enable debugging tool for my App:

“C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\plmdebug.exe” /enableDebug WPFUWP_1.0.0.1_x86__s46g25shpckvj “C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\WinDbg.exe -c g”

5. Launch the App and recreate the crash issue. The Windbg will auto-break the crash point, and stop App running or existing.

6. Open Windbg, in the command line, run this command:

.dump /ma /u c:\output\crash.dmp

Then can start check the crash.dmp as postmortem analysis by debugging expert.

After getting dump, can run this command to auto attach debugger on my app:

plmdebug /disableDebug WPFUWP_1.0.0.1_x86__s46g25shpckvj

 

Thanks,

Freist

(84)

行动起来:转换传统桌面应用程序到UWP 并发布到Windows 应用商店!

 

一个月前微软发布了桌面应用程序转换器(Desktop Application Converter),让我们可以把现有的桌面应用程序(.NET 4.6.1 或 Win32)轻松转换成 通用 Windows 平台 (UWP) 的程序。

这实际上为开发者带来了巨大的机会。目前已经看到许多开发商主动开始这个过程并成功转换,发布到了 Windows 应用商店。 目前有超过3 亿 5000 万的设备正在运行 Windows 10,这种转换为有价值的桌面应用程序提供了前所未有的易于展现和购买的渠道。

不过,在这个过程中,我也注意到有两个常见的问题︰

A. 我成功转换此应用程序,它运行得相当好,但似乎没有办法直接发布到 Windows 商店?

B. 真是太酷了! 但是转换需要下载很大的image (3.5GB+) 和安装特定环境,我还没空尝试。。。。.

当然也有其他的问题,比如一些细节的准备工作,如何添加一些代码来在传统桌面程序里面使用 UWP API,有其它参考链接对此做了详细解释,在这里我主要回答上面两个问题:

关于问题 A,当决定转换并通过Windows应用商店发布自己的桌面应用程序时(不管会不会转换)都可以通过微软官方链接提交请求 (这个表格目前还是英文,但不难理解, 在提交的时候请注明来自国家地区,并附上本文博客链接)︰

https://developer.microsoft.com/en-us/windows/projects/campaigns/desktop-bridge

微软应用咨询团队(包括我在内)将帮助这个过程,包括解决转换中的技术问题,创建一个用来发布应用程序的特定开发者帐户。我们需要在这里特定开发者帐户,是因为转换后的应用程序,需要”runFullTrust”,这就是转换后的程序不能直接将其发布的原因。

关于 B 的问题,我开发创建了”Desktop Bridge Online” 的Azure 服务,它可以帮助开发人员上传和转换的应用程序(写了个调用DAC的 windows 服务) 在线快速 (几个点击和文件名输入)︰

https://bridge10.azurewebsites.net

这项服务可能没有涵盖所有极端复杂的安装转换场景,但会满足大多数转换需求。

结果将是一个 zip 文件包含转换后的Appx程序包、测试证书和 程序包的分析文件。目前的应用程序安装程序文件大小仅限于 500 MB。如果您的安装程序是上面的文件大小,鼓励安装本地转换环境。这里是主要的用户界面︰

clip_image002

转换选项如下所示参数的含义参考 https://msdn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-run-desktop-app-converter

clip_image003

希望上面的信息和新的在线工具可以让我们更好地协助需要转换桌面应用程序的开发人员。任何反馈随时让我知道。

从 Windows 应用程序咨询团队更有益的参考:

https://blogs.msdn.microsoft.com/appconsult/2016/10/13/desktop-bridge-the-bridge-between-win32-apps-and-the-universal-windows-platform/

https://blogs.msdn.microsoft.com/appconsult/2016/10/17/desktop-bridge-converting-an-installer/

Thanks!

Freist Li

(86)

Take Action: Convert your Windows Desktop App and bring it to Windows 10 Store

 

One month ago Microsoft released the Desktop App Converter (DAC), which enables you to bring your existing desktop apps written for .NET 4.6.1 or Win32 to the Universal Windows Platform (UWP).

The tool makes the conversion process quite easy and help you determine what minor changes, if any, are required.

We are glad to see many developers proactively start the process and successfully converted their converted desktop apps to the Windows 10 platform and release it to the Windows Store , which is visible by 350+ million devices are running Windows 10 today, and releasing to the Store is a great way to increase the exposure of the apps.

However, we also noticed there are two common questions on the process:

A. I converted this app successfully, it works quite well, but seems no way to directly published to Windows Store?

B. It’s so cool! But the converting requires downloading big image (3.5G+) and setup specific environments, I don’t have time to quickly give a try yet……

There are also other questions related to preparations, how to step further to add some code and make the app use UWP API, this can be explained in some reference links, here I want to give direct ideas on above two questions A & B.

Regarding question A, after you decide to publish your converted App (if converted app doesn’t work, that’s okay) to Windows Store, please submit a request to us through this form link:

https://developer.microsoft.com/en-us/windows/projects/campaigns/desktop-bridge

Our Application Consult team will help you to see if there is any real technical block of the converted app, if the converted app works well as APPX package, then the team will help you create a specific store account to publish the App. We need specific store account here because the converted app requires “runFullTrust” capability, this is the reason you cannot directly publish it.

Regarding question B, I’m glad to let you know that I created “Desktop Bridge Online (beta)” service on Azure recently, which can help developers to upload and convert the App online (internally through a windows service wrapping Desktop App Converter) quickly (several clicks and filename inputs). Here is it:

https://bridge10.azurewebsites.net

This service may not cover all complicated installation converting scenarios, but will be quite help as an alternative option for common scenarios.

The result will be a zip file includes converted files, test certificate, and package analysis file. At the moment the App installer file size is limited to 500MB. If your installer is above the file size, encourage setup the local converting environment. Here is the main UI:

clip_image002

The convert options follow the parameters guide of DAC:

clip_image003

Hopefully the information and new tool can make our developers experience better on the App converting. Any feedback feel free to let me know.

Welcome to UWP world and happy coding!

More Useful References from Windows App Consult Team

https://blogs.msdn.microsoft.com/appconsult/2016/10/13/desktop-bridge-the-bridge-between-win32-apps-and-the-universal-windows-platform/

https://blogs.msdn.microsoft.com/appconsult/2016/10/17/desktop-bridge-converting-an-installer/

 

Thanks

Freist Li

(70)

Node.JS Diagnoser Site Extension for Azure Web APP is Ready

In my latest post, introduced that the default Node.JS version (0.10.32, x86) parser function is embedded in Azure Web APP DaaS.

Here the Node.JS Diagnoser Site Extension is provided specifically for diagnosing more Node.JS versions (0.12.6 X86 and X64) and more flexible operations. In simple words, now it supports analyzing:

0.10.32 X86

0.12.6 X86

0.12.6 X64

To use it:

1. Install Node.JS Diagnoser Site Extension from https://portal.azure.com

a. Open Azure Portal, navigate to App Services -> your Web App -> Tools -> Extensions.

b. Click Add, and choose Node Diagnoser to install it.

Note: After the Site Extension was installed (take around 30 seconds), the portal will restart App by default. You may want to do this installation during non-business hours if business requires.

clip_image002

2. After installation, access https://<appname>.scm.azurewebsites.net/nodediag

3. To analyze all running node processes directly, click Analyzing Running Node button. You can click SafeStop at any time if want to stop the analyzing.

clip_image004

4. To analyze the node process separated, click the FullDump button in front of the node process. After dump generated completed (the file size doesn’t change in the Dump File List), click 32bitAnalyzer (if the node process is X86) or 64bitAnalzyer (if the node process is X64).

clip_image006

After several minutes, the report zip will display in the Report List section. User can download and unzip the report package, view Indext.html. For details refer to this article.

image

image

In future, the support version list can be added per users’ feedback. And we will also consider embedding popular versions into DaaS.

Thanks,

Freist Li

(588)

How to analyze Node.JS running processes on Azure Web APP

 

Node.JS Parser for Node.JS 0.10.32 32bit is included in Azure Web App Diagnostic Service now.

If you have Node.JS 0.10.32 32bit running, and want to quick analyze its running status, open https://<appname>.scm.azurewebsites.net/support

Click the Analyze menu, click Diagnostics, and then click Diagnose Now:

clip_image002

The parser is developed to analyze Node.JS slow performance issue or understand process running status at given time. It works as analyzing Node.exe directly and generating diagnostic report for it. Currently it supports the default Node.JS version on Azure Web APP (0.10.32 X86) with multiple instances.

After report generated, download the report zip file and unzip it.

Note: To analyze other Node.JS versions which are not supported in DaaS yet, please check:

http://blog.freistli.com/2016/03/09/node-js-diagnoser-site-extension-for-azure-web-app-is-ready/

There is is a HTML report. To quick go through the report, click the report link in the index page index.xhtml:

clip_image004

Then in the detailed report page, click the Menu items on left pane

clip_image006

The report information includes:

Node.exe Process Summary

On the Process section, you can hover mouse cursor around counters, it can give more explanations in tooltip

clip_image008

Threads Running Time

This lists all thread running time in User Mode

clip_image009

Running HTTP Request

If the main thread runs a HTTP Request, it will dump out URL and Query information.

clip_image010

JavaScript call stack on Threads

Node.JS executes sync tasks on one single main thread. If there is any JavaScript code running on the single main thread, the report will parser the JavaScript call stack as below:

clip_image012

For the call frame which runs JavaScript function, click the Hyperlink of the call frame number, the function source code will be displayed and rendered with JavaScript Syntax:

clip_image014

Native C/C++ and JS Stack Traces on Threads

This gives you a complete view for all running call frames on each thread, not only JavaScript, but also native calls (such as Node and V8 modules). Regarding the thread which contains JavaScript frames, it also shows Arguments object list for each JS frame.

clip_image016

Active Handles in Async Queue

Node.JS supports async calls. It is possible that all threads don’t explicitly execute JavaScript tasks on call stacks, but many async tasks are pending executing or waiting for callback. The pending async tasks associate active handles in the async queue (a double link structure). By looking at the handles and related objects we can know the nature of those async tasks and then perform necessary tuning.

This section gives latest 100 active handles and wrapped objects info:

clip_image018

Click the hyperlink of the object address, it displays the Object properties:

clip_image020

Memory Usage

This part provides a flat memory usage summary from different memory category:

clip_image022

 

Thanks,

Freist Li

(599)

How to capture and analyze dump for intermittent High Memory on Azure Web App

Previous posts introduced how to capture dumps for intermittent Exception and High CPU issues on Azure Web App. Today Crash Diagnoser V1.3 supports High Memory dump capture too. Here are quick configure steps:

1. Install Crash Diagnoser from Site Extension Gallery. For detailed installation steps, click here. If you installed it before, can update it from Microsoft Azure Portal.

clip_image002

2. Open https://yourwebapp.scm.azurewebsites.net/crashdiag , click the 2nd Chance Unhandled Exception tab, choose your target process name. The default options include w3wp, node, php-cgi.

If you want to monitor other process, such as mywebjob.exe, just type the process name mywebjob manually in the field.

3. Select the Monitor Memory field as “Yes”. Set the Memory Threshold, and Memory Type (Private or Virtual). The summary info explained details.

Note: This guide simply used 2nd chance exception + Monitoring Memory scenario. Actually either 1st chance or 2nd chance Exception, CPU and Memory monitoring rules can be used at the same time.

clip_image004

4. Click the Start button. Will see the title status changes:

clip_image006

5. If the high memory issue happens, the dump will be generated and displayed in the Dump File List:

clip_image008

6. The cool thing is you can directly analyze the generated dump files now (for exception, high cpu, high memory, etc.) by click the Analyze button. Generally you don’t need manually download dump and perform offline analyze on them through Windbg/DebugDiag now. The analyzed report can be downloaded and viewed in the Report File List:

clip_image010

A report sample:

image

More Information Regarding Crash Diagnoser

===============================

How to capture intermittent exceptions on Azure Web APP

Troubleshoot Stack Overflow on Azure Web APP

Tips of Crash Diagnoser

How to capture High CPU dump on Azure Web APP

Thanks.

Freist

(66)

How to capture dump when intermittent High CPU happens on Azure Web App

 

When facing intermittent High CPU issue on Azure Web App, previously we have no easy method to capture dump files for further analysis because:

1. It is an intermittent issue. When you monitor the application, the high CPU may not happen at the moment or in the current process lifecycle.

2. When use Kudu site to run procdump to capture the High CPU dump, the procdump may exit before issue happens once Kudu console gets timeout/refresh, and then cause target process terminated.

Now with latest Crash Diagnoser (V1.1.0.0), we can quickly configure and capture the High CPU dump. Below is the guide:

1. Open Azure Portal, navigate to App Services -> your Web App -> Tools -> Extensions.

2. Click Add, and choose Crash Diagnoser to install it.

Note: After the Site Extension was installed (take around 10 seconds), the portal will restart App by default. You may want to do this installation during non-business hours if business requires.

clip_image001_thumb[1]

3. Please make sure the web app configuration is “AlwaysOn” because the Crash Diagnoser runs as a Continuous web job. Refer to: http://blog.amitapple.com/post/73574681678/git-deploy-console-app/#.VpcHaPl96Ul

4. After installation, select it from the Installed Web App Extension blade, click Browse:

clip_image002_thumb[1]

5. Click the 2nd Chance Unhandled Exception tab, choose your target process name. The default options include w3wp, node, php-cgi.

If you want to monitor other process, such as mywebjob.exe, just type the process name mywebjob manually in the field.

6. Select the Monitor CPU field as “Yes”. Set the CPU Threshold (the CPUs usage percentage to trigger dump action, the percentage is for all cores), and Duration (the CPU usage needs to be equal or above the threshold for the specific seconds). The summary info explained details.

clip_image004_thumb[1]

If you want to set other parameters, click the Advanced Settings

7. Click the Start button. Will see the title status changes:

clip_image005_thumb[1]

8. That’s All. If the target process meets the high CPU pattern, or crashed with unhandled exception, the useful dump will be generated immediately:

clip_image007_thumb[1]

9. Click the hyperlink of the files to download them, and you can analyze them with DebugDiag offline.

 

More Information Regarding Crash Diagnoser

===============================

How to capture intermittent exceptions on Azure Web APP

Troubleshoot Stack Overflow on Azure Web APP

Tips of Crash Diagnoser

 

Thanks.

Freist

(88)

How to use CrashDiag Site Extension to Capture Dump for Intermittent Exception issues or performance issues on Azure Web App

 

While running Customer’s .NET/PHP/ Node processes in Azure Web App environment, it may intermittently crashes due to code or performance issues. It’s important to capture the crash dump when such crash/exception happen automatically for further investigation.

This article is to introduce the new CrashDiag Site Extension, which can easily help us to capture the necessary data when intermittent unhandled exception happens. Now it can work for these scenarios:

Capture Dump for Exceptions

1.     Unhandled Exception happening

2.     Specific first chance exception happening based on filtering parameter

3.     Monitoring new launched processes continuously

4.     Configure total dump file numbers and debugger process instances

5.     Native App, Managed App, Web Job with 32bit/64bit

6.     Safe Stop at any time without terminating target process

Capture Dump for Performance (slow, high CPU, high Memory)

1. Capture Hang Dump on Demand

To capture dump for exceptions, follow below steps:

1. Install

2. Configure (1st chance or 2nd chance exception handling):

3. Start

4. Stop

Install

1. Open Azure Portal, navigate to App Services -> your Web App -> Tools -> Extensions.

2. Click Add, and choose Crash Diagnoser to install it.

image

3. Please make sure the web app configuration is “AlwaysOn” because the Crash Diagnoser runs as a Continuous web job. Refer to: http://blog.amitapple.com/post/73574681678/git-deploy-console-app/#.VpcHaPl96Ul

Configure

1. After installation, select it from the Installed Web App Extension blade, click Browse:

image

2. Now we can configure it based on our troubleshooting scenarios (1st chance or 2nd chance exception handling):

2.1 Application Crashed (unexpected terminated due to 2nd chance unhandled exception)

2.1.1 Click the 2nd Chance Unhandled Exception tab, choose your target process name. The default options include w3wp, node, php-cgi.

If you want to monitor other process, such as mywebjob.exe, just type the process name mywebjob manually in the field.

clip_image0074_thumb1

2.2 Application didn’t crash, but has specific exceptions generated. We need to filter 1st chance exception and perform analysis.

2.2.1 Click the 1st Chance Exception tab, set the exception code and process name.

Besides the default options of exception code, you can type other specific code which occurred on the application. For example, if the application reported FileNotFound exception, you can type FileNotFound or NotFound in the Exception Code field.

To monitor all 1st chance exceptions, type *

But this may generate other kind of dump files other than you expected.

image

3. Click the Advanced Settings tab to make sure the settings are properly for you. The current default setting are suitable for common scenarios, you can tune them as you wish.

Consider one dump can be hundreds MB size, you may want to set the Maximum dump file number less than 10.

clip_image0114_thumb1

Start

1. After configuration, click the Start button to start monitoring. If your application is running, around 10 seconds, you will see the CrashDiag status changed from “Stopped on Instance name” to “Monitoring Processes on Instance name”:

clip_image0134_thumb1

2. If the application crashed, you will see the *.dmp files are generated in the output path. In this sample, it is in d:\home\logfiles\crashdiag. Then You can open Kudu portal and further investigate the dump file.

Stop

1. After troubleshooting, click SafeStop to stop the Crash Diagnoser. This Stop action will not terminate the target process and can be executed at any time.

If the Instance is running a Crash Diag, and you click Start again, the portal will reminder you to safe stop it first:

clip_image0153_thumb1

 

To capture dump for performance issues, follow below steps:

1. Click the Process tab, click Load List to show current running processes

2. Click FullDump, the dump will be created and shows in the Dump File List section

clip_image0173_thumb2

Question & Answer

1. After install the Site Extension, will the Web App be restarted?

Yes. It will be restarted as applicationhost.xdt is used in the package. Without restarting, the route to CrashDiag cannot be found.

2. Can it analyze dump automatically?

Not Yet. Its current purpose is to capture intermittent exception data as dump files for root cause analysis.

3. If I set target process as W3WP, will it monitor the Kudu site W3WP process as well?

No. It will not capture processes which is running for Kudu, DaaSConsole, and DaaSRunner

4. If the site extension is updated, will it be auto-updated?

Yes. It will be auto-updated. A popup message will remind you for this:

clip_image0193_thumb1

Your web app will not be restarted during the auto-update.

5. If I don’t know which kind of exception I’m facing, how to configure it?

Please check if there is Process Terminated or Exit logs in the D:\home\LogFiles\eventlog.xml when the issue happened. If yes, then can use 2nd chance exception configure as above.

Normally 1st chance exception will not cause application crash. If you need to capture dump for it, please understand the performance impact on the target process can be a little higher than the 2nd chance exception capture. This is because the debugger needs to filer all 1st exceptions happen in the target process.

6. Will it monitor all Web Instances?

Through this UI, it will only monitor the current Instance in the current Kudu site (https://appname.scm.azurewebsites.net/crashdiag) instead of all instances.

The SafeStop option will stop all monitoring tasks on all instances.

7.  How to download the dump files?

Open Kudu portal, navigate to the output folder, and download them. Or download from CrashDiag file list directly by click the File link.

image

Thanks

-Freist

(48)

How to use CrashDiag to capture Stack Overflow exception dump in MVC Web APP on Azure

This article is to show how to capture a real stack overflow exception happened in MVC web app on Azure. Actually after reading you will find this method can be used to solve other web apps which has intermittent 1st chance exception issues.

The sample MVC web app is from a small test project from https://github.com/freistli/Dev14_Net46_Mvc5/tree/StackOverflow. When run it and click the Contact menu, the application will immediately exit and shows this error on Azure Web App:

clip_image002_thumb1

In this sample, we know it is a fatal c00000fd exception (native stackoverflow exception). If in real production situation cannot retrieve the code info from event log or other logs, can contact Microsoft Support Team to see if can get exit code from backend logging tables.

To further investigate the exception, we expect to take the crash dump exactly when the exception happens. Now let’s use CrashDiag:

1. Install Crash Diagnoser site extension from the Azure Site Extension Gallery from Azure Portal. For detailed installation steps please refer to this article.

Please make sure the web app configuration is “AlwaysOn” because the Crash Diagnoser runs as a Continuous web job. Refer to: http://blog.amitapple.com/post/73574681678/git-deploy-console-app/#.VpcHaPl96Ul

2. Browse the extension (https://yourtestapp.scm.azurewebsites.net/cashdiag). Click the 1st chance exception tab, set the setting as:

image_thumb7

Please notice The Managed Exception option is selected as “No” because it is a crash on native exception code c00000fd

The reason we don’t configure and capture 2nd chance unhandled exception for the MVC app is ASP.NET by default captures unhandled 1st chance exceptions in HTTP Context directly and makes an exit. It quits directly after those “fatal” 1st chance exceptions without throwing 2nd chance exception.

If you saw StackOverflowException exception code was recorded in d:\home\logfiles\eventlog.xml, it means the exception is managed exception:

<Data>w3wp.exe</Data>
<Data>IIS APPPOOL\TestWeb</Data>
<Data>StackOverflowException</Data>
<Data>Operation caused a stack overflow.
at testWeb._Default.Page_Load(Object sender, EventArgs e)
at System.Web.UI.Control.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()

Then you should set exception code as “overflow” or “StackOverflowException”, Managed Exception as “Yes”:

image_thumb5

3. Click the Start button. The CrashDiag starts monitoring w3wp process.

image_thumb9

4. Once the c00000fd exception happens, the dump can be generated automatically. After dump is generated completedly (the file size doesn’t change for 10 seconds), click the file name to download it.

image_thumb11

Then we can use debugging tool (Windbg or DebugDiag) to debug the dump to see how the exception happens. This sample dump shows calls tack as below, then it accurately points to the Foo() function caused the process termination:

0:22:> kL

ChildEBP RetAddr

059ce610 067755f6 Dev14_Net46_Mvc5!Dev14_Net46_Mvc5.Controllers.HomeController.Foo()
059ce610 067755f6 Dev14_Net46_Mvc5!Dev14_Net46_Mvc5.Controllers.HomeController.Foo()+0x6
059ce610 067755f6 Dev14_Net46_Mvc5!Dev14_Net46_Mvc5.Controllers.HomeController.Foo()+0x6
059ce610 067755f6 Dev14_Net46_Mvc5!Dev14_Net46_Mvc5.Controllers.HomeController.Foo()+0x6
059ce610 067755f6 Dev14_Net46_Mvc5!Dev14_Net46_Mvc5.Controllers.HomeController.Foo()+0x6
059ce610 067755f6 Dev14_Net46_Mvc5!Dev14_Net46_Mvc5.Controllers.HomeController.Foo()+0x6
059ce610 067755f6 Dev14_Net46_Mvc5!Dev14_Net46_Mvc5.Controllers.HomeController.Foo()+0x6
private void Foo()
        {
       
         Foo();
        
        }

Thanks

-Freist

(24)