Showing posts with label Bug. Show all posts
Showing posts with label Bug. Show all posts

Tuesday, August 19, 2014

Why Visual Studio 2010 closes itself without loading the UI when we launch devenv.exe

On a fine day, I could see that my Visual Studio stopped loading up, when I try to start VS IDE. It shows the splash screen for some seconds and then popup an alert dialog as below and exit itself.

The 'Microsoft.VisualStudio.TeamFoundation.PowerTools.TfptPackage, Microsoft.VisualStudio.TeamFoundation.PowerTools, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' package did not load correctly.


The problem may have been caused by a configuration change or by the installation of another extension. You can get more information by running the application together with the /log parameter on the command line, and then examining the file 'C:\Users\<user>\AppData\Roaming\Microsoft\VisualStudio\10.0\ActivityLog.xml'.

I could see that the devenv.exe process is not present after the alert box. As usual first option I tried was restarting the machine. But that didn't help me.

Then I uninstalled the VS 2010 team foundation power tools as its mentioned in the message. Restarted machine. Still no improvement. Then I tried running VS in safemode to make sure none of the plug-ins are getting loaded which might caused error while loading. No luck.

After the above step I understood that its something complicated and I need to run the Visual Studio with logging enabled so that I can examine the log. After running with log enabled, I was able to see the below suspicious entry in the log file.

<entry>
    <record>39</record>
    <time>2014/08/08 18:11:33.997</time>
    <type>Warning</type>
    <source>VisualStudio</source>
    <description>The CTM file is out of date and should be deleted and rebuilt, but the file &apos;C:\ProgramData\Microsoft\VisualStudio\10.0\1033\devenv.CTM&apos; could not be deleted.</description>
  </entry>

What is this CTM file? I did some google and got some links to fix it. But unfortunately nothing worked out.

I had to spent half day to reach this point. There was no benefit researching on this as its taking my productive time. So decided to re-install Visual Studio. Then the next issue started. I am using VS 2010 Ultimate and the infrastructure team in my office don't have the DVD as the license is with client. So finally settled in installing VS 2012 Pro in my machine. I had to agree on that as VS is my tool. That day went smooth with VS 2012.

On next day out of curiosity, I tried to launch VS 2010 and surprisingly it worked. Still this time, its a wonder for me.

Monday, December 2, 2013

Unable to debug 64bit .net app in VS 2010, because sos is not getting loaded

Recently I had to debug one of our research application for memory leaks. It is developed in Visual Studio 2010 as 64 bit .Net application with considerable amount of unmanaged (Win32 API) calls. Since I have Visual Studio 2010 Pro, thought of debugging in VS itself, for just a change.

How to debug in Visual Studio using sos extensions

Initially I enabled the unmanaged debugging in the project properties which is the first thing to do when starting sos debugging in VisualStudio. Then I tried loading sos as usual in Immediate window.

.load "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\sos.dll"

But it ended up as

Error during command: extension c:\windows\microsoft.net\framework64\v4.0.30319\sos.dll could not load (error 193)

Oh I forgot one thing, we cannot debug 64 bit applications in VS 2010 because VS 2010 process is running as 32 bit even the OS and machine are running in 64 bit. I can see devenv.exe is a 32bit process in Task Manager, but I am not sure about the reason but people says it.

Thats fine. I changed the application to x86 ie 32 bit. Then I tried to load sos. But surprised to see another error message.

.load C:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll
Error during command: IDebugClient asked for unimplemented interface
Error during command: Exception c0000005 occurred at 2A5E7EAE

This is interesting. I had no other way except googling the same error message. The first result itself told that there is an issue reported to Microsoft on this

If there is .Net 4.5 installed we cannot load sos in VS 2010

http://connect.microsoft.com/VisualStudio/feedback/details/742882/after-installing-visual-studio-11-beta-load-sos-fails-in-visual-studio-2010

I have .Net 4.5 installed in my machine which I cannot un-install for this silly thing. Yes I had to go back to WinDbg, the command line world to do my job.

Monday, November 14, 2011

Generic retry mechanism & catch using generic exception type

Couple of weeks back we faced one situation where a portion of our code breaks due to a IIS not available situation and we were advised to implement a retry mechanism.Hope I can talk about that server down problem in future posts. The retry mechanism needs to implement based on the exception which will occur on that particular scenario. We tried test code by putting the try catch block and could see its working in one place. But there  are a bunch of other areas we need to modify the code.Also in future too developers may need to use this retry mechanism.
The architect resting in me jumped and said that we can use a generic retry mechanism using .net generics. My colleagues were in little confusion about how to achieve a generic mechanism for retry where the size and location of code differs and spread out in 150 projects.With the help of Action delegate I was able to convince them and the subsequent google gave us ready made code to do the same.
public static void ExecuteWithRetry( Action action, UInt16 noOfAttempts )
{
    //Validate args:Throw exception on retryCount=0
    int count = 1;
    for (; ; count++)
    {
        try
        {
            action();
            break;
        }
        catch (ReTryableException ex)
        {
            Log(ex, count);
            if (count == noOfAttempts) throw;
        }
    }
}

Everybody became happy like after the first fight seen in movies. We know that the movie needs to complete its 2 hours with excitement and for that villain  should come back with more power. Here too the villain come back when the perfectionist in me put forward the suggestion of making it real generic so that we can move to the utility project and can be consumed by other fellow developers as well. So we rewrote the logic as follows.


public static void ExecuteWithRetry<TException> ( Action action, UInt16 noOfAttempts ) where TException :Exception   
{
    //Validate args:Throw exception on retryCount=0
    int count=1;
    for(;;count++)
    {
        try
        {
            action();
            break;
        }
        catch (TException ex)
        {
            Log(ex, count);
            if (count == noOfAttempts) throw;
        }
    } 
}

Oh what an idea sir ji…There was one more suggestion came to make retry after specific interval. But before that we tried to integrate modified function in our app.

Catching exception using generic type

Here starts the second part of the story. When we run from Visual studio it didn’t hit the catch block!!! Theoretically there are no issues but practically it failed. At least for some moment surrounding people even I thought that our understanding about either Exception handling or generics is wrong. Even we thought of getting rid of this concept and write redundant retry code everywhere. But when we came back to our original state , we googled it and find that it is a BUG in .Net when running inside Visual Studio debugging mode.We tried running by double clicking the application and it works perfect.We were also able to see this bug in the Microsoft connect and says its fixed.

There is on workaround available for this issue its as follows

catch (Exception ex)
{
    TException tEx = ex as TException;
    if (tEx != null) { /*Process */}
    else throw;
}

This changed my perception

“The bug is there only due to poor dev’s coding mistake never by compilers, development tools or the framework”

to

“Compilers, development tools and frameworks are also coded by developers”.

Later I happen to read a post about fixing a compiler bug which enforced my perception.