views:

110

answers:

4

Hi, I wrote a C# application that is running well on my xp development machine. When my client is running it on different PC, it seems to freeze on both vista and 7 machines. I would like to know if there is any issue on running dotnet applications on vista/7. I compiled the application for both framework 2.0 and 3.5 but it didn't help. The log file neither doesn't help. Is there any way to know where is the application freezing (of course, the client doesn't have VS for attaching to the application) ? Thank you in advance for any help.

Pierre.

A: 

You do not give much information in order for us to help a great deal.

I would start by trying to recreate the issue locally on a virtual machine (vista one available here) and then profiling the app with something like memprofiler.

redsquare
I have a windows 7 PC but I was not able to recreate the problem.
Pierre
:) Yes, most weird issues cannot be reproduced on just another machine.
Lex Li
+2  A: 

Generally, .NET application should run the same on any Windows version with .NET framework installed. Most common problem that occur are related to the new User Account Control policy in Vista and 7, which prevents applications from accessing areas requiring elevated privileges (which would otherwise run fine under an Administrator account in XP).

For example, if your application is trying to write configuration settings to the Program Files folder (which is a really bad idea, btw), or is using some hardcoded disk or registry paths instead of environment variables provided in .NET classes, it may fail under Vista.

To quickly check if this is an UAC privilege problem, try to run the application as an administrator (have your client right click the .exe file and select Run as Administrator). If it works, then this suggests that you need to examine your code and update it to make sure you are only accessing allowed areas.

Check this link for more information: Making apps UAC aware.

As redsquare suggested, the best way to test your application in a variety of Windows systems is to run them in several virtual machines (MS Virtual PC or VMWare Player, both of them free for download).

Groo
this is a good point but I have a windows 7 PC and it seems to run. I suppose I am not covering the area of code my client is covering but it is hard to say. The best would be to have a debugger that could attach to the freezed application to get the stack trace I think.
Pierre
In house testing can never capture all issues, like the one Pierre faced. Therefore, other approaches must be used. Ask your client to use a debugger can be too hard if he/she is not a developer. Usually a process dump is easier to capture and it provides enough information for troubleshooting.
Lex Li
A: 

Ask your client to capture a process dump using Windows Task Manager,

  1. In Task Manager, find the process that hangs.
  2. Right click and capture a memory dump.

Then you can do some analysis on the dump to see why it hangs.

If you are not familiar with dump analysis, find someone who can help or open a support case via http://support.microsoft.com

Lex Li
I got a dmp file from my client.I loaded Microsoft symbols but I cannot load dotnet symbols and my application symbols.I added the application bin/debug dir to symbol path but it seems to load nothing.Here is the call stack, it doesn't help me :
Pierre
> ntdll.dll!_KiFastSystemCallRet@0() user32.dll!_NtUserWaitMessage@0() + 0xc bytes System.Windows.Forms.ni.dll!68bb8ea8() [Frames below may be incorrect and/or missing, no symbols loaded for System.Windows.Forms.ni.dll] System.Windows.Forms.ni.dll!68bb8ea8() System.Windows.Forms.ni.dll!68bb8997() System.Windows.Forms.ni.dll!68bb87e1() System.Windows.Forms.ni.dll!68b75931() mscorwks.dll!_CallDescrWorker@20() + 0x33 bytes mscorwks.dll!_CallDescrWorkerWithHandler@24() + 0x9f bytes mscorwks.dll!MethodDesc::CallDescr() + 0x15a bytes
Pierre
mscorwks.dll!MethodDesc::CallTargetWorker() + 0x1f bytes mscorwks.dll!MethodDescCallSite::CallWithValueTypes_RetArgSlot() + 0x1a bytes mscorwks.dll!ClassLoader::RunMain() - 0x39040 bytes mscorwks.dll!Assembly::ExecuteMainMethod() + 0xa4 bytes mscorwks.dll!SystemDomain::ExecuteMainMethod() + 0x416 bytes mscorwks.dll!ExecuteEXE() + 0x49 bytes mscorwks.dll!__CorExeMain@0() + 0x98 bytes mscoreei.dll!71f455ab() mscoree.dll!_ShellShim__CorExeMain@0() + 0x227 bytes mscoree.dll!__CorExeMain_Exported@0() + 0x8 bytes
Pierre
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
Pierre
Sounds like you know little about .NET debugging, so follow my advice and consult Microsoft support team.
Lex Li
Well I know a lot about debugging in VisualStudio but not about analysing dump file.Otherwise I wouldn't ask for help.I am just looking for someone who already did it and could help me to save some time.I already had a look on the support web site but I didn't find the answer to this problem.
Pierre
A: 

csharp applications are supposed to run on vista/win7. This is their home:)

Your problem is not the OS. its your application. Most probably the application is looking for a file, a folder, something on the client side that is not there and its freezing. this is my experience.

Check for project independencies and make sure you have shipped to your clients everything your project needs.

and last, distribute to one client the debug version with debug messages enable and get the feedback from their system.

Ray