Debugging/Comparing Managed or .net memory dumps using Visual Studio 2013

Visual Studio 2013 comes with a new feature called “Debug Managed Memory” this feature also allows to compare managed memory usage across two dumps.  Read on…

This is how you would open a .net 4.5 memory dump in Visual Studio…

imageimage

So for the purpose of this blog I’ve created memory dumps of a managed application that consumes high memory: memtest.exe. I’ve collected three memory dumps…

  1. MemTest.dmp
  2. MemTest (2).dmp
  3. MemTest (3).dmp

For demo purpose I’m opening MemTest (3).dmp ‘first’ as shown in the above screenshot. So once you open the dump in Visual studio this is how Visual Studio will look like…

image

Check out mouse cursor location in the above screenshot. Click on this option. You’ll following dialog pop up….

image

Following which you’ll see the following screen…

image

This report will show the most number of objects on heap. If you notice the largest objects in my case are ArrayLists and second one is MemTest.Form1, too many forms. The also shows you the roots to an object.

Further in the above screenshot, I’ve highlighted an item in red. That option allows us to compare multiple dumps. The resultant report will show you the diff view between the two dumps. For demo I’m comparing MemTest (3).dmp with MemTest.dmp. MemTest (3).dmp was collected after  memtest.dmp was collected so you should ideally see a positive diff between the two dumps as the memory is increasing. See screenshot…

image

You’ll see that, new columns has been added to this report, for e.g. “Cound Diff.”, ‘Size Diff (Bytes)” etc. The bottom table shows you the “Reference Count Diff.” as well.

Really cool feature! Comparing managed memory has been never easier. Please note this feature is only enabled for.net memory dumps that use .net 4.5.

 

[Video] What’s cool in Visual Studio 2013 Solution Explorer

A video presentation on what’s new and cool in Visual Studio 2013 Solution Explorer…

I’ll follow up this presentation with some more presentation on what’s some of the cool things in Visual Studio 2013 just to speed up anyone who’s hopping onto the Visual Studio 2013 wagon.

 

VisualBasic PowerPack missing from Visual Studio 2013?

Note the power pack is not part of Visual Studio 2013 install, it comes as separate MSI. The download link for Visual Basic Powerpack for Visual Studio 2013 is hard to find online as well. I found the link from our internal support article.

Download VB Powerpack (direct link to bits): http://go.microsoft.com/fwlink/?LinkId=321343

image

Please close any open instances of Visual Studio 2013. Once the installation completes and if you still don’t see the Powerpack controls in the toolbox. Do the following.

  1. Open Visual Studio 2013
  2. Open the toolbox. Add a new tab, right click on the toolbox, select “Add Tab”. Name the tab to “Visual Basic PowerPack”
  3. Expand the new “Tab”. Right click in the empty space under the new tab and select “Choose Item”. You’ll see the following dialog popup…
    image
  4. Please give it few minutes to load all items. Please select “.Net Framework Components” tab if its not already selected.
  5. In the filter text box control please type in “Power”. You should see something like this in the above dialog…
    image
  6. Check the relevant ones and add them to your toolbox as shown below…
    image
  7. Once you click ok, you should see the following controls added to your toolbox…
    image
  8. In my case I’ve added all powerpack controls to my toolbox.
  9. You might also have to add a reference to this new powerpack library if you still see compilation errors. Be aware that the assembly name has changed as well…
    image

We’ve had couple of customer’s who report that Visual Basic powerpack is missing from Visual Studio 2013.
http://connect.microsoft.com/VisualStudio/feedback/details/801421/microsoft-visualbasic-powerpacks-vs-dll

Enjoy the powerpack.

 

[Debugging] Application crash after migration from Visual Studio 2005 to 2008

Had a customer whose application was crashing after migration from Visual Studio 2005 to Visual Studio 2008. He had the crash dumps as well. The crash call stack had some CRT string format functions like vsprintf. This gave to us a fair inkling that parameters passed in are wrong.

Customer had a format string, something like this: “My string format [%s]”.

At the point of crash the output buffer looked like this: “My string format[“. It became quite evident that the crash is happening when the %s in the format string was being replaced by the actual string. Quite evident that something’s wrong with the parameter passed in for replacing the %s format specifier.

Checking code saw something like this…

MyString mystr = “MS rocks”;
MyFormatters::Format(“My string format [%s]”, mystr);

You should never do this. %s is expecting a “raw string” and do not pass in anything else. This is wrong even if your class has a raw string as its first member, imagine if you have a virtual function in the class or if someone decides in the future this class should be derived further.

Always pass in a raw string pointer and nothing else to the string format functions for expanding the format specifier: %s. The string format family of functions doesn’t check the type passed in. Those functions work on varargs hence compiler doesn’t help as well.

In this case we fixed above code likewise:
MyFormatters::Format(“My string format [%s]”, mystr.c_str());

You might have an obvious question as to why it worked in Visual Studio 2005, the answer is pretty obvious as well. I’ll leave that for you to answer.

 

[Debugging] How to find length of a CString string in application memory or in a dump

Recently a colleague of mine asked where’s the length of CString string stored in memory. Hmm so lets dig around. Please note I’ve declared the following CString object in my code…

CString TestCString = _T("Nibu is testing CString");

If you dump CString type in the debugger we see following…

0:000> dt TestCString
Local var @ 0xb4fcd4 Type ATL::CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t> > >
   +0x000 m_pszData        : 0x00dfa2f8  "Nibu is testing CString"

From above dump of type CString we see that CString class defines just one variable: m_pszData. I don’t see a length variable here so where is the length stored for CString string?

Length of a CString string is stored at a negative offset from m_pszData. The data structure that resides at the negative offset is: ATL::CStringData

0:000> dt mfc100ud!ATL::CStringData
   +0x000 pStringMgr       : Ptr32 ATL::IAtlStringMgr
   +0x004 nDataLength      : Int4B
   +0x008 nAllocLength     : Int4B
   +0x00c nRefs            : Int4B

CStringData is retrieved via a call to function: GetData()

CStringData* GetData() const throw()
{
    return( reinterpret_cast< CStringData* >( m_pszData )-1 );
}

The above code is bit of pointer arithmetic, first m_pszData is cast to a pointer to CStringData and then the casted type is deducted by –1 (which will equate to -sizeof(CStringData). So lets see while debugging if we can get to the CStringData located at a negative offset. First lets get the size of ATL::CStringData in memory.

0:045> ?? sizeof(ATL::CStringData)
unsigned int 0x10

Size of ATL::CStringData comes to 0x10 bytes. So in my test application lets find out what is located at a negative offset of 0x10 bytes. In my current frame I’ve the following locals. My CString object is called TestCString, highlighted in bold in the below code snippet.

0:000> dv
           this = 0x00ef6ba8
        cmdInfo = class CCommandLineInfo
       ttParams = class CMFCToolTipInfo
      InitCtrls = struct tagINITCOMMONCONTROLSEX
   pDocTemplate = 0xcccccccc
    TestCString = class ATL::CStringT<wchar_t,StrTraitMFC_DLL<wchar_t,ATL::ChTraitsCRT<wchar_t> > > 
     pMainFrame = 0xcccccccc

Deduction of 0x10 bytes from address of m_pszData (0x00dfa2f8) gives us the address: 00dfa2e8

0:000> ? 0x00dfa2f8-0x10
Evaluate expression: 14656232 = 00dfa2e8

Lets try dumping out CStringData located at the address: 00dfa2e8. See below

0:000> dt 00dfa2e8 TestStack!ATL::CStringData
   +0x000 pStringMgr       : 0x786cb8e4 ATL::IAtlStringMgr
   +0x004 nDataLength      : 0n23
   +0x008 nAllocLength     : 0n23
   +0x00c nRefs            : 0n1

Dump type says, length of string is: 0n23 which is correct. The length of string “Nibu is testing CString” is indeed 23.

Code documentation of CStringData says this about its member variables…

struct CStringData
{
    IAtlStringMgr* pStringMgr;  // String manager for this CStringData
    int nDataLength;  // Length of currently used data in XCHARs (not including terminating null)
    int nAllocLength;  // Length of allocated data in XCHARs (not including terminating null)
    long nRefs;     // Reference count: negative == locked
    // XCHAR data[nAllocLength+1]  // A CStringData is always followed in memory by the actual array of character data

Difference between nDataLength and nAllocLength is quite evident from the above documentation. Hope this helps.

 

[Debugging] Application high memory usage on Windows 8.1

Recently had a customer who was complaining about high memory usage on Windows 8.1. The application consumed about 140 MB on a Windows 8.1 OS as compared to a meager 3 to 4 MB on a Windows 7 or 8 machine.

Hmm interesting. Being experienced in troubleshooting for sometime now this smelled to me like an issue with some kind of debug flag settings. So immediately checked with customer if he has accidently left some GFlags setting configured.

Reminded me of a customer who had an issue wherein all the application on his box started showing high memory usage, eventually this turned out to be an issue with a system wide flag configured via GFlags. GFlags is a helpful tool but please do remember to undo the changes once you’re done with the debugging. Probably stick a sticky somewhere which will hint you to turn off these settings.

So coming back to this incident, hmm why would the application consume high memory on Windows 8.1. Note: He had the application compiled using VS2008.

Checked memory dump of Test.exe running on Windows 8.1 in our debugger and saw that it has some heap validation features enabled. This is the reason why huge amount of memory is being consumed since these heap validation features will require extra memory.

0:000> !heap
Index   Address  Name      Debugging options enabled
  1:   00300000                 tail checking free checking validate parameters
  2:   00c20000                 tail checking free checking validate parameters
  3:   00200000                 tail checking free checking validate parameters
  4:   02170000                 tail checking free checking validate parameters

I was bit surprised as the customer said he doesn’t have GFlags on his box. So I renamed Test.exe to Test1.exe and this is what the dump shows now. Looks like someone’s enabling heap validation flags on Test.exe.

0:000> !heap
Index   Address  Name      Debugging options enabled
  1:   001d0000                
  2:   00c20000                
  3:   02220000                
  4:   00390000

The application memory usage, after renaming, came down to 3.5 MB.

image

Eventually we figured out who’s turning the heap validation flags on. The integrated Application Verifier included in the Visual Studio Team Suite and Visual Studio Team System for Developers versions of Visual Studio was turning these features on and that was expected as well. The customer had pro version hence he probably didn’t see the settings in project properties. This is how the project property pages will look like…

image

So if you have application verified standalone application installed on your box you’ll see your application listed there as Visual Studio turns certain registry settings on/off based on your settings. Once your application starts up these settings will take effect. Troubleshooting is fun isn’t it. Smile

 

[MFC Feature Pack] Select an MDI tab programmatically in a Document View application

A customer recently asked this question, thought I’ll share the solution out here. Its not that obvious FYI. When creating an MFC MDI application we have an option to enable tabbed view of MDI documents. Once this is done here’s how the application will look like…

imageimage

image

Note that except for the first sample image you have multiple tab groups in the rest of the screenshots , this is an inbuilt facility provided by the tabbing framework of MFC. This is important when selecting a tab programmatically: You’ll also have to decide which tab from which group you would like to select.

In MFC framework tab groups are represented by CMDIClientAreaWnd::GetMDITabGroups() which returns a member variable of type CObList. This is how the code looks like…

const CObList& GetMDITabGroups() const { return m_lstTabbedGroups; }

This is a list of tab controls. Each tab control in this group denotes a tab group. So when activating a tab we’ll have to decide which tab in a tab group should be activated.

Following sample code activates the first tab in all the tab groups. Please note tab index starts at zero.

void CMainFrame::OnViewActivatetab()
{
    const CObList& TabGrps = m_wndClientArea.GetMDITabGroups();
    for (POSITION pos = TabGrps.GetHeadPosition(); pos != 0;)
    {
        CMFCTabCtrl* pNextWnd = DYNAMIC_DOWNCAST(CMFCTabCtrl, TabGrps.GetNext(pos));
        pNextWnd->ActivateMDITab(1);
    }
}
 

Visual Studio 2013 successfully Released to Web

Some useful links…

Visual Studio 2013 Available Now!
Visual Studio 2013 Highlights
System Requirements and Platform Compatibility
Known issues for Visual Studio 2013 (Readme)
Known issues for .NET Framework 4.5.1 (Readme)
Known issues for Visual Studio Team Foundation Server 2013 (Readme)
Windows Store is now open for submitting apps targeting Windows 8.1

 

[MFC]Application migrated from VS2005 to VS2010 crashes on XP

The crash happens as a result of requesting a non-existent API via GetProcAddress, the API is GetThreadPreferredUILanguages. GetProcAddress returns 0xFFBADD11 (a known issue with windows XP where GetProcAddress returns NON-NULL) which means LDRP_BAD_DLL.

To fix this issue override CWinApp::LoadAppLangResourceDLL and prevent loading of the lang dll or set the WINVER macro to target XP builds so that the code using the non-existent API is not compiled into the application (hope its wrapped in a #define).

 

Announcing our third Windows Phone 8 update—plus a new developer preview program

By: Darren Laybourn, Corporate Vice President, Windows Phone

A bigger Start screen for more Live Tiles. A new, customizable Driving Mode. Better accessibility options.

These are just some of the new features and innovations that we’re getting ready to deliver to you in Windows Phone 8 Update 3, which will roll out to existing phones over the next several months. As manager of the engineering team responsible for delivering updates to your Windows Phone, today I wanted to tell you a bit more about what’s included in our third official update of the year—plus describe a new preview program we’re launching to help developers keep their apps running smoothly on our latest software.

It’s been a busy but exciting year for my team—and Windows Phone overall. If you follow the news, you might have seen that our market share in Europe has grown to nearly 10 percent. We’re seeing things really start to accelerate. We believe this is because we continue to advance the platform at a rapid pace. Our hardware partners, meanwhile, have been taking advantage of this innovation by releasing amazing new Windows Phone devices throughout the year.

The story behind No. 3

When we sat down to plan our latest official update to Windows Phone 8, we had three main engineering goals in mind:

  1. Enable incredible new Windows Phone devices.
  2. Enhance the platform with new capabilities for current users and partners.
  3. Improve overall quality.
Support for bigger, higher-resolution screens

So the new update paves the way for future Windows Phone devices with 5- and 6-inch touch screens. The larger, 1080p HD displays on these devices will make Windows Phone even more personal—for example by sporting jumbo-sized Start screens with room for six Live Tiles across instead of four.

A bigger Start screen means the ability to pin even more of the people, info, and apps that matter to you. Built-in apps and Hubs like email, Photos, People, and Music and Videos will also be carefully scaled to take full advantage of the additional real estate on 6-inch screens.

A Start screen with room for as many as six Live Tiles side by side.  Windows Phone 8 Update 3 paves the way for larger Start screens like this on future Windows Phone devices with 5- and 6-inch touch screens.

More powerful hardware

In addition to larger screens, Update 3 will also bring support for the Qualcomm Snapdragon 800 quad-core processor. The added horsepower that this chip delivers should make our already-fluid operating system perform even better.

Driving Mode

A new feature called Driving Mode helps you get from point A to point B with fewer distractions. Working with a connected Bluetooth device, Driving Mode is designed to limit notifications on the lock screen—including texts, calls, and quick status alerts—until you’re safely parked.

A new feature of Windows Phone 8 Update 3 called Driving Mode helps you get from point A to point B with fewer distractions.

You can even configure Driving Mode to send automatic replies to people who call or text when you’re behind the wheel, to let them know you’ll get back to them.

New accessibility features

Another highlight of the new update is Mobile Accessibility for Windows Phone 8, which isn’t a single feature but a suite of apps designed to make Windows Phone easier to see, hear, and use. The apps, which include a screen reader, make it easier for blind and visually impaired users to manage calls and contacts, send texts and emails, browse the web, make Skype and Lync calls, and hear notifications like alarms, calendar events, and low-battery warnings.

Improved Internet Sharing

Many of you are familiar with the Internet Sharing feature, which turns Windows Phone 8 into a mobile hotspot by sharing your cellular data connection over Wi-Fi.

In Update 3, we’ve made it easier to use your phone as a data-savvy hotspot for Windows 8.1 devices. Just pair your phone and Windows 8.1 PC or tablet over Bluetooth, tap your network name, and you’ll be connected and ready to go. No need to enter a password or dig out your phone and turn on Internet Sharing—it’s done for you.

But, wait, there’s more

That’s not all we’ve packed into Windows Phone 8 Update 3. Besides hundreds of under-the-hood performance tweaks and enhancements, we’ve also added a bunch of small but handy new features, including several that you’ve been asking for. They include:

  • More useful ringtones: With Update 3, you can use custom ringtones for more things—including instant messages, emails, voicemails, and reminders. You can also assign custom ringtones to contacts for text messages, so you’ll know who’s texting you without even looking.
  • No more twist and shout: Does your screen keep spinning when you’re trying to read emails in bed? Use the new rotation lock option to keep it fixed in place.
  • Better storage management: New storage settings make it easier to free up space on your phone and manage temporary files. A new category view shows what’s taking up space at a glance.
  • Easily close apps: Now you can use the App switcher to quickly close apps when you’re finished with them.
  • Wi-Fi access out of the box: You can now connect to Wi-Fi during phone set up, so you can start conserving cellular data right out of the box.
  • Better Bluetooth: The team made a bunch of improvements to improve connection quality for Bluetooth accessories.

Windows Phone 8 Update 3 adds the ability to assign custom ringtones to contacts for text messages, so you'll know who's texting you without even looking.Does your screen keep spinning when you’re trying to read emails in bed? Use the new rotation lock option to keep it fixed in place.

As you can see, there’s some fun and handy stuff in Windows Phone 8 Update 3. If you have suggestions for future updates, submit them to our Windows Phone Suggestion Box site. We always appreciate the feedback and take it into account as we prioritize new work.

So when will all this be coming to your phone? As I mentioned earlier, the rollout initially kicks off in the coming weeks and will continue over several months. Specific timing depends on a number of factors including your carrier and phone model.

Announcing the Developer Preview Program

Finally, today I’m also happy to announce the Windows Phone Preview for Developers. The program, which officially launches later today, gives app builders early access to our operating system updates so they can verify that their apps work as expected on the new code.

To participate and download Windows Phone 8 Update 3, you need to meet one of three conditions: your phone is “developer-unlocked,” you’re a registered Windows Phone Store developer, or you’re a registered Windows Phone App Studio developer.

You’ll find more details about the new program in a post today on our official Developer Blog. Try it out and let us know what you think, and thanks for your continued interest in Windows Phone!

Darren Laybourn, Corporate Vice President, Windows Phone

Announcing our third Windows Phone 8 update—plus a new developer preview program