.NET Application Crash error without debugging information

Question

I have a backup program that currently runs in our corporate environment on approximately 70 machines. A mixture of laptops, desktops and Windows (xp-32, vista-32, vista-64, 7-32-7-64) without problems.

There is one exception, and that is the reason I am posting help here.

On a single Dell Latitude machine running Windows 7 64 bit with .Net 4 Framework installed, the console application will crash before it launches Sub Main. It just gives a generic Windows error, "The problem caused the program to stop working correctly." without the ability to see debugging information.

Things I tried:
- Removing all non-standard software
- Commenting on a few statements that I thought might cause problems
- Recompiled for Auto CPU, x86 and x64 to find out if this has changed - - Virus scan disabled
- The user is an administrator, but I tried to run it as an administrator
- A mailbox was added to Sub Main to determine where it failed
- Added catch attempt to all relevant code

I managed to get a little more information from the event viewer:

Module name error: KERNELBASE.dll, version: 6.1.7600.16385, timestamp: 0x4a5bdbdf
Exception Code: 0xe0434f4d Error Offset: 0x0000b727

These next few entries seem strange to me:

Failure ID: 0x% 9
Application crash time: 0x% 10
Application path error:% 11
Fault Module path:% 12

I also managed to pull up a .wer file (Windows Error Report Flat File) and it hid much of the same information, but also included downloaded DLL files and other files.

Thank you for taking the time to read my wall of text, and hopefully someone will have ideas on how to proceed.

Joshua

edit:

I think the following calls to the Win32 API might cause problems, and these were the only things that I could not easily comment on without a lot of code rewriting.

If so, why only on this machine :(

' Obtain a handle to the console application window by passing the title of your application. Dim hWnd As Integer = Process.GetCurrentProcess().MainWindowHandle Dim hMenu As Integer = GetSystemMenu(hWnd, False) 'WIN API Functions to assist in disabling the Close button on the Console Window Private Declare Function DeleteMenu Lib "user32" (ByVal hMenu As Integer, ByVal uPosition As Integer, ByVal uFlags As Integer) As Boolean Private Declare Function GetForegroundWindow Lib "user32" () As Integer Private Declare Function GetSystemMenu Lib "user32" (ByVal hWnd As Integer, ByVal bRevert As Boolean) As Integer Private Declare Function GetWindow Lib "user32" (ByVal hWnd As Integer, ByVal uCmd As Integer) As Integer Private Declare Function GetWindowText Lib "user32" Alias "GetWindowTextA" (ByVal hWnd As Integer, ByVal lpString As String, ByVal nMaxCount As Integer) As Integer Private Declare Function ShowWindow Lib "user32.dll" (ByVal hWnd As Integer, ByVal nCmdShow As Int32) As Boolean Public Declare Function WNetGetConnection Lib "mpr.dll" Alias "WNetGetConnectionA" (ByVal lpszLocalName As String, ByVal lpszRemoteName As String, ByRef cbRemoteName As Integer) As Integer 

Answer 1

I would first look at Tess Ferddanes' blog , it has information on creating a debug file when it crashes and viewing it using windbg

second I would try to restore the structure on one of these machines, since we had a similar deployment problem and that resolved the problem.

Answer 2

I would change all your descriptor references (hwnd) to IntPtr, since this data type will work in any .NET infrastructure, but I do not believe that the integer data type will work in a 64-bit environment for the descriptor descriptor.

The following is also information from the Microsft article:

In general, .NET Framework assemblies written in Visual Basic will work the same regardless of platform. However, there are some cases that behave differently on different platforms. These are common cases:

Structures containing elements that vary in size depending on the platform, for example, any type of pointer.

Pointer arithmetic, which includes constant sizes.

Invalid platform calls or COM declarations that use Integer for descriptors instead of IntPtr.

Passing IntPtr to Integer.

Using the invoke platform or COM interoperability with components that do not exist on all platforms.

The full article can be found here: http://msdn.microsoft.com/en-us/library/8ck8e1y2(v=vs.80).aspx

Answer 3

Check out the merge log to see the build of your download. You may not find the assembly you are trying to load.

How to enable assembly failure logging (Fusion) in .NET

EDIT: Wild shot in the dark ... Is the quick user switch feature enabled on this machine? If so, try disabling.

http://www.addictivetips.com/windows-tips/how-to-enable-disable-fast-user-switching-in-windows-xp-and-windows-vista/

Answer 4

This error occurs sometimes when you have 32-bit DLLs (or mixed 32-bit and 64-bit DLLs) that compile for anyCPU and run on a 64-bit system. I know you said you tried compiling for x86, but try to make sure ALL DLLs are 32-bit and then compiled for x86.