jreddy's Blog

Inside Developer Support Engineer

2007-12-16T23:18:00Z

This post reflects my experiences as Developer Support Engineer for around 22 months.I was a Developer Support Engineer in VC/C# support team.Hopefully this will give some knowledge to others who wonder about what this role is.

Though one expects you to be technically sound and have good communication skills, one should also be passionate about helping others.If you are not interested in helping others, no matter how intelligent you are, succeeding in this role will be difficult.

Other things that you will also learn from this job is,

Commitment - This is one thing that can change your life. Be it for personal or professional life, guys with this quality will definetly score more than others.

When we call a Customer service support, with the expectation of getting some help,If we notice that she/he is willing to help, though he/she is not able to help, we feel good. Though in many occasions, we were are not able to help directly,we ensured that,our customers get the help they wanted with the help of others.

Trust - Any relationship will start with Trust. We feel bad when we don't get help when we want.Again, help can be in the form of giving a feeling that our problem will get resolved.We learned to inform our customers, if there are any delays in we contacting them, as promised. We kept them informed about our back-up person, in case if we are sick,out-of-office.

Customer satisfaction revolves around the above two areas mainly. As a company, Microsoft gives top priority to those qualities and wins customers.They do "everything" for customer.

It is like going to a big management institute and learning how to win customers.To be frank, I started applying those qualities in my personal life also and I can see the difference.

Though,I personally had difficulties working during the night times(Though i sleep during the day time i used to feel like not having enough sleep), missing out colleagues get together parties(If everone goes for party, we will miss customers). Extra effort to keep our customer instantly as far as possible, If I look back and see with what i have gained, I am very happy.

Now that I moved to a different role, thankfully I don't have all those problems. Change is constant, To be happy, we should learn to love the work.

Marking Applications on Windows Vista Using Manifests

2007-01-26T15:44:00Z

I am copying the text from the article http://msdn2.microsoft.com/en-us/library/aa480150.aspx with respect to changes that one needs to make in a manifest file if they want to run the applications on vista

Note:When you compile the application using Visual Studio 2005 on Vista it will not by default add the below changes (Atleast for the time being).

You need to create a manifest file with the below setting and specify it under the

Project Properties->Configuration Properties->Manifest Tool->Input and Ouput->Additional Manifest Files

Marking Applications on Windows Vista Using Manifests

In Windows Vista, the correct way to mark your applications is to embed an application manifest within your program that tells the operating system what the application needs. In the Windows Vista release, there are provisions to allow non-manifested or unsigned code to run with administrative privileges. In future releases, the ONLY way to run an application elevated will be to have a signed manifest that identifies the privilege level the application needs.

Application Manifest Schema

Application manifests are not new to the Windows Vista release. Manifests were used in Windows XP to help application developers identify such things as which versions of DLLs the application was tested with. Providing the execution level is an extension to that existing manifest schema.

The Windows Vista application manifest has been enhanced with attributes that permit developers to mark their applications with a requested execution level. The following is the format for this.

Copy Code

<requestedExecutionLevel
   level="asInvoker|highestAvailable|requireAdministrator"
   uiAccess="true|false"/>

level

asInvoker—The application runs with the same token as the parent process.
Important note For Windows Vista Beta-1, the term used for this level is leastPrivilege. Developers wishing to mark their code for this level on Windows Vista Beta-1 should use leastPrivilege. Developers will need to update their manifest to use the term asInvoker in subsequent versions of Windows.
highestAvailable—The application runs with the highest privileges the current user can obtain.
requireAdministrator—The application runs only for administrators and requires that the application be launched with the full token of an administrator.

uiAccess

false—The application does not need to drive input to the UI of another window on the desktop. Applications that are not providing accessibility should set this flag to false. Applications that are required to drive input to other windows on the desktop (on-screen keyboard, for example) should set this value to true.
true—The application is allowed to bypass UI protection levels to drive input to higher privilege windows on the desktop. This setting should only be used for UI Accessibility applications.

Vista, how is it going to impact Visual Studio and applications developed using that?

2007-01-09T13:03:00Z

As Vista released, Developer who are using Visual Studio to develop applications will have lot of questions

Please refer "Visual Studio and Windows Vista"

http://msdn2.microsoft.com/en-us/vstudio/aa948853.aspx and

Frequently Asked Questions http://msdn2.microsoft.com/en-us/vstudio/aa948854.aspx

How to troubleshoot Manifest generation problems

2006-09-19T19:23:00Z

As a support engineer I have been troubleshooting so many cases where Visual Studio 2005 was throwing an error
while generating an external manifest file, while embedding manifest, while using additional manifest files.

It is important to know "How does VS 2005 Embed Native Manifest Files" to troubleshoot this type of issues.
Here is a blog that clearly explains the internals of manifest generation along with parameters that is passed to link.exe, mt.exe
http://blogs.msdn.com/zakramer/archive/2006/05/22/603558.aspx

Fatal Error C1060 compiler is out of heap space

2006-08-23T16:25:00Z

There is possibility of getting the above error when you compile a C++ application that is making heavy use of templates with covariant return types

I had a customer who was getting the above error (As a support engineer I thought I can write a post that might be helpful for users who come across the above error)

We tried suggestions as specified in msdn2.microsoft.com/en-us/library/yz7kx3y2.aspx

We also tried clearing TEMP Folder.

After checking in our internal database I came to know that it is by design.

The following are the workarounds suggested

1) using shorter names or 2) less complicated class templates or 3) remove the usage of covariant return types.

In this case we got rid of the above error by removing covariant return types

Manifest file?? When did this come into the picture

2006-08-22T14:17:00Z

As a support engineer I have come across a customer who was not able to run a VS2003 compiled app that is using a VS2005 compiled DLL ( He is using Load Library to load the DLL)

Here is his scenario

a) VS2003 compiled app(net_run.exe) using VS2003 compiled DLL (net_setcmn_test.dll)- No problem ( Some customers will not have VS2005 DLL)

b) VS2003 compiled app(net_run.exe) using VS2005 compiled DLL(net_setcmn_test.dll) - It throws "The application failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem"

Customer has ensured that he installed vcredist_x86.exe.

c) After troubleshooting for sometime, he created a manifest file for net_run.exe with name net_run.exe.manifest and copied the following content (from the manifest file of net_setcmn_test.dll.intermediate.manifest)

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
<dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
</dependency>
</assembly>
After that he is able to run the app. He approached us complaining that the above workaround will not work if his customer doesn't have VS2005 DLL and hence no vcredist DLL's.

He wants to know how to make his app to work with both VS2003 DLL's and VS2005 DLL's

He also claimed that with some system configurations it recognizes the manifest and with others it doesn't.

Here is what we found

>>> Pre Win-XP are manifest ignorant. Win-XP and above will recognize manifest file

I was under the assumption that Loader will look into the manifest only if it is compiled using VS2005

** With respect to the customer's problem, I found that his VS2005 compiled DLL doesn't have embedded manifest file( This is recommended in http://msdn2.microsoft.com/en-us/library/ms235342.aspx)

** I embedded manifest file using mt.exe -manifest net_setcmn_test.dll.manifest -outputresource:net_setcmn_test.dll;2 and removed net_run.exe.manifest

This time I am able to run the application without any issues.

** Found that customer is building from the command line and needs help with linker switches so that it automatically takes care of embedding the manifest file.

Suggested him the following link http://blogs.msdn.com/zakramer/default.aspx.

Visual Studio "servicing" Site

2006-03-07T22:09:00Z

Here is the link where we can get some info on Visual Studio 2005 service pack release date

http://msdn.microsoft.com/vstudio/support/servicing/default.aspx

Troubleshooting C/C++ Isolated Applications and Side-by-side Assemblies - Scenario based with solutions

2005-12-23T21:20:00Z

I am a support Engineer and has handled large number of cases related to C/C++ Isolated applications and side-by-side assemblies.

I came across different errors and is able to find resolution with the help of my Escalation Engineers. Here is the list of errors along with the solution. I hope this will help my team mates or users who has same set of errors.

I always suggest one to go thru http://msdn2.microsoft.com/en-us/library/ms235342.aspx .
In Most of the cases the above link is sufficient enough to find out the solution.

Scenario 1:

C Run-Time Error R6034
Error Message
"An application has made an attempt to load the C runtime library incorrectly. Please contact the application's support team for more information."

In VC++ 2005, you need an application manifest to make use of the CRT (msvcr80[d].dll). If your application or DLL using CRT DLL doesn't have a manifest, you get this error.

Solution
Rebuild your application with a manifest
http://msdn2.microsoft.com/en-us/library/ms235560.aspx

Scenario 2:

Error Message
The application failed to initialize properly (0xc0000135).
This application has failed to start because the application configuration is incorrect. Reinstalling application may fix this problem.
The system cannot execute the specified program.

If a manifest is present in your application but a required Visual C++ library is not installed in the WinSxS folder, you may get one of the above error messages depending on the version of Windows on which you try to run your application:

Solution
Event viewer will have more details that will help us in finding a solution.

Scenario 3:

Error Message
This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem.

Typically this error occurs because you are mixing retail and debug components. A very common scenario is a debug build of a application which is pulling in a retail version of a static library. The scenario could be the exact reverse and the error message in this case would reference msvcr80d.dll

Solution
This can be worked around by adding reference to retail CRT in the application manifest manually. Or by adding the following to a header.

#pragma comment(linker, "\"/manifestdependency:type='Win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='X86' publicKeyToken='1fc8b3b9a1e18e3b' language='*'\"")

Note: Proceed with caution when providing this solution.

Scenario 4:

ErrorMessage
Though there are no runtime errors,there might be errors in event viewer like

Component identity found in manifest does not match the identity of the component requested Syntax error in manifest or policy file

"C:\Client\Microsoft.VC80.MFC.MANIFEST" on line 4. Generate Activation.Context failed for C:\Client\test.dll. Reference error message: The operation completed successfully

There are 2 bugs which cause this.

1. The assembly manifest of Microsoft.VC80.MFCLOC is incorrect. It has version 8.0.50727.42 instead of 8.0.50608.0.

Solution
Change the version number

should be changed to
<assemblyIdentity type="win32" name="Microsoft.VC80.MFCLOC" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"/>

2. Microsoft.VC80.MFCLOC is referenced not by the application but by MFC80[ud].dll

Solution
Microsoft.VC80.MFCLOC directory has to be under Microsoft.VC80.MFC directory and not at the same level.

Scenario 5:
Works in Windows XP but not in Windows Server 2003 or vice versa. On Windows XP the stand alone manifest overrides the embedded manifest where as in Windows Server 2003 the embedded manifest always overrides the stand alone manifest.

It is recommended to have embedded manifest with correct information.
This will also avoid the overhead of shipping external manifest.

Scenario 6:
Can't find the MSM for ia64 under C:\Program Files\Common Files\Merge Modules.

Solution
Make sure you have installed one of the Team Editions and that you have selected the tools for building ia64 and merge modules in setup. The Professional SKU does not have ia64 support.

Scenario 7:
VS 2005 setup did not install the RTM version of MSM for libraries in \Program Files\Common Files\Merge Modules. Or the MSM under \Program Files\Common Files\Merge Modules indicate they are for beta2. In explorer, hovering over the VS 2005 MSMs shows tooltips which shows "WinSxS Beta 2".

Solution

This is bug in the MSMs. Even though there are RTM they were mislabeled with "WinSxS Beta 2". The version should still show 8.0.50727.42. You can find the version by adding the MSM to a setup project and checking version under properties. There is a QFE which updates this label if customer needs it - KB 911884.