none
.Net App failure on Vista

    Question

  • CAN SOMEONE HELP ME??????

    I have developed an App that uses: C# (client App) and managed/unmanaged C++ framework that all resides on a separate DLL. The App works fine when I run it on my development PC (WinXP intel/x86), however when I package it for another user (using Vista 64bit) the Application fails to startup. I built the App using MS Studio 2005 (.Net framework 2.0).

    I ran Dependency Walker on it on my PC, and although it had errors saying: delay-load dependency module was not found error (IESHIMS.DLL & WER.DLL) and another warning for:  unresolved import due to a missing export function in a delay-load dependent module (MPR.DLL); it still ran. I had the other Vista user run Dependency Walker on his install version, and it had different missing module errors and warning. We were able to find all the missing modules and copied them to the install directory, but there was 1 warning left for: unresolved import due to a missing export function in a delay-load dependent module (for: IEFRAME.DLL). The App still failed to launch. So it seems to be the IEFRAME.DLL warning. Then I copied the SAME version (of IEFRAME.DLL ver: 8.0.6001.18702) from my PC to his installed directory, however it Still came up with that error, and failed to launch (of course) I don't know why this is happening; its the same version on our PCs.

    I was able to install the App to a Laptop (running Vista 32bit Intel/x86). Althought it failed first I copied my IEFRAME.DLL (and my MFC80.DLL) over to that laptop and it was working (go figure). I also tried to run Profiling from Dependency Walker, on my PC (which runs fine stand-alone), but it failed to startup (???). Here is the log from that Profiling:

    --------------------------------------------------------------------------------------------
    Starting profile on 6/5/2009 at 12:52:19 PM

    Operating System: Microsoft Windows XP Professional (32-bit), version 5.01.2600 Service Pack 3
    Program Executable: c:\develop\callcenter\bin\release_client\CALLCENTER.EXE
    Program Arguments:
    Starting Directory: C:\Develop\CallCenter\bin\Release_Client\
    Search Path: C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\MySQL\MySQL Server 5.0\bin;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;C:\Program Files\QuickTime\QTSystem\;C:\Program Files\CMake 2.6\bin

    Options Selected:
         Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.
         Log DllMain calls for process attach and process detach messages.
         Log DllMain calls for all other messages, including thread attach and thread detach.
         Hook the process to gather more detailed dependency information.
         Log LoadLibrary function calls.
         Log GetProcAddress function calls.
         Log thread information.
         Use simple thread numbers instead of actual thread IDs.
         Log first chance exceptions.
         Log debug output messages.
         Use full paths when logging file names.
         Automatically open and profile child processes.
    --------------------------------------------------------------------------------

    Started "c:\develop\callcenter\bin\release_client\CALLCENTER.EXE" (process 0x56C) at address 0x00400000 by thread 1.  Successfully hooked module.
    Loaded "c:\windows\system32\NTDLL.DLL" at address 0x7C900000 by thread 1.  Successfully hooked module.
    Loaded "c:\windows\system32\MSCOREE.DLL" at address 0x79000000 by thread 1.  Successfully hooked module.
    Loaded "c:\windows\system32\KERNEL32.DLL" at address 0x7C800000 by thread 1.  Successfully hooked module.
    DllMain(0x7C900000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\windows\system32\NTDLL.DLL" called by thread 1.
    DllMain(0x7C900000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\windows\system32\NTDLL.DLL" returned 1 (0x1) by thread 1.
    DllMain(0x7C800000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\windows\system32\KERNEL32.DLL" called by thread 1.
    DllMain(0x7C800000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\windows\system32\KERNEL32.DLL" returned 1 (0x1) by thread 1.
    Injected "c:\program files\microsoft visual studio 8\common7\tools\bin\DEPENDS.DLL" at address 0x08370000 by thread 1.
    DllMain(0x79000000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\windows\system32\MSCOREE.DLL" called by thread 1.
    DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\program files\microsoft visual studio 8\common7\tools\bin\DEPENDS.DLL" called by thread 1.
    DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "c:\program files\microsoft visual studio 8\common7\tools\bin\DEPENDS.DLL" returned 1 (0x1) by thread 1.
    GetProcAddress(0x7C800000 [c:\windows\system32\KERNEL32.DLL], "FlsAlloc") called from "c:\windows\system32\MSCOREE.DLL" at address 0x790068DF and returned 0xFFBADD11 by thread 1.
    Exited "c:\develop\callcenter\bin\release_client\CALLCENTER.EXE" (process 0x56C) with code 1282 (0x502) by thread 1.

    Friday, June 05, 2009 5:03 PM

All replies

  • I'd hazard a guess that your DLL is compiled as 32-bit, wheras your .NET code is targetting AnyCPU. Therefore when run on an x64 machine, the .NET jitter generates 64-bit code and then can't load the 32-bit DLL (since you can't mix 32 and 64 bit code in process). Changing your .NET executable to target x86 only should solve the problem.
    Saturday, June 06, 2009 10:15 AM
  • Hello dirobins

     

    I second AndyCadley’s idea that the problem results from the incompatible bitness between your host process and the loaded dlls. You can change your .NET exe to target x86 only in project properties / Build / Platform target / select x86.

     

    For the second question regarding the 1282(0x502) error when you profile the exe in dependency walker, this is likely to be a product issue of Dependency Walker. The error 1282(0x502) means STATUS_STACK_BUFFER_OVERRUN. It seems that Dependency walker does not work well with .NET assemblies. I suggest contacting the owner of the tool, Steve P. Miller (http://stevemiller.net/email/).

     

    Best Regards,

    Jialiang Ge


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Monday, June 08, 2009 3:09 AM
    Moderator
  • Guys,
    Thanks for the info. I will try changing the Build Platform and let you know if it works.
    Monday, June 08, 2009 7:29 PM
  • Guys,
    I tried that and it STILL doesn't work. Any other ideas???
    Tuesday, June 09, 2009 8:55 PM
  • Hello dirobins

     

    First of all, let’s try to figure out the exact error that causes the load failure of the app.

     

    Can you show us the profile log of dependency walker for the app when the app is launched on the machine that gives the failure (e.g. the Vista 64bit machine)? The log should be helpful to show what the problem is.

     

    In addition, I have a few more suggestions that deserve your test if the dependency walker log does not tell anything useful.

     

    1. When the app is normally launched (by doubled clicking it in windows explorer), do you see any error message box prompted? If yes, please let me know the error message.

     

    2. In case that the issue is related to its incompatibility with Vista (e.g. due to UAC), I suggest using the Microsoft Application Compatibility Toolkit 5.5 to analyze the problem. http://www.microsoft.com/downloads/details.aspx?FamilyID=24DA89E9-B581-47B0-B45E-492DD6DA2971&displaylang=en. The 22 mins video demonstrates the use of ACT: http://edge.technet.com/Media/Be-ready-for-Windows-7-Application-Compatibility/.

     

    3. In case that the issue has something to do with SxS (http://msdn.microsoft.com/en-us/library/aa376307.aspx), please enable the SxS tracing to log the errors due to SxS. Junfeng has a nice blog illustrating how to diagnose SxS failures: http://blogs.msdn.com/junfeng/archive/2006/04/14/576314.aspx.

     

    Best Regards,

    Jialiang Ge


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Wednesday, June 10, 2009 3:55 AM
    Moderator
  • Hello dirobins

    How are you? It's been a couple of days since our last contact. May I know the current status of the issue on your side? Were my suggestions useful to you? If you have any other questions or concerns, please feel free to tell me.

    Best Regards,
    Jialiang Ge
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Friday, June 12, 2009 3:12 AM
    Moderator
  • Hey Jialiang,
    As far as running Profiler on the Failed machine, that would be useless because I cannot successfully run Profiler on any machine in which the App runs fine (as my original problem stated). I think you mention that it was a Bug with Profiler running .Net Apps. I did email the creator of Dependency Walker, but no reply as of yet. If you have any idea of how to successfully run Profiler for a .Net App which uses managed/Unmanaged C++ Dll, then let me know.

    As your other suggestions:
    1. When the App is launched (on the failed machine), the user sees a "Application Failure" dialog that pops-up alerting to either Send Failure Information to Microsoft OR Just close the App. There is a details options, which creates a Dump file. I cannot open that dump file (I tried) but it complained that I cannot open 64bit Dump Files; I'm on 32bit XP. The only way to open it up, according to Visual Studio, is to Remote Debug the process. It is tough to do that because the machine is a user's PC that is inaccessable to me. I created a small Test App, and was thinking of slowing adding function from original App, in order to see at what point it breaks; AND also to install Visual Studio on the users machine and build it there. We'll see!!!

    2. As far as the Compatability Toolkit, I don't think that would work for me because I already installed the App on a 32bit Vista laptop and it worked. So it seem to be a 64bit Vista problem, Not necessary strictly Vista entirely. Still trying to figure it out...

    3. I haven't tried the SxS logging yet. I have copied my versions of the SxS files (MFC & CRT Dlls), but that didn't work. I will try loggin of SxS and will keep you updated.

    I really do appreciate the help you are offering, and thank you for it. I just wish I could figure what the ____ is going on with this. If you have any more suggestions please feel free to share them.

    Thanks,
    David
    Friday, June 12, 2009 4:57 PM
  • Hello dirobins

     

    I understand the frustration to hunt for the culprit of the problem in the dark. My suggestion is to try various tracing tools or debuggers to find the clue (e.g. a meaningful error message). As long as the clue is found, I’m sure that it can be resolved easily.

     

    Here are a few more tracing and debugging tools that may help you:

     

    1. When you see “Send Failure Information” dialog, WER in Vista or WS2008 generates a crash dump file:

    http://blogs.technet.com/askperf/archive/2008/02/05/ws2008-windows-error-reporting.aspx

    The crash dump should contain the error info and the thread context when the problem happens. If you are fine with analyzing dump with windbg or VS debugger, you can try it by yourself. Otherwise, you may consider sending the dump file to me (jialge at microsoft.com)

     

    2. If WER is not enabled on your computer, you can use AdPlus to capture the crash dump:

    http://support.microsoft.com/default.aspx/kb/286350

     

    3. Process Monitor is a very useful tracing tool for trace the behaviors of processes.

    http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

    You can attach procmon to the process, and see if it logs any errors in the output.

    The video http://www.microsoft.com/emea/spotlight/sessionh.aspx?videoid=346 illustrates the use of process monitor in detail.

     

    4. Try Assembly Binding Log Viewer (Fuslogvw.exe)

    http://msdn.microsoft.com/en-us/library/e74a18c4.aspx

    The Assembly Binding Log Viewer displays details for assembly binds. This information helps you diagnose why the .NET Framework cannot locate an assembly at run time. These failures are usually the result of an assembly deployed to the wrong location, a native image that is no longer valid, or a mismatch in version numbers or cultures. The common language runtime's failure to locate an assembly typically shows up as a TypeLoadException in your application.

     

    Best Regards,

    Jialiang Ge


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.
    Tuesday, June 16, 2009 4:06 AM
    Moderator