.NET Application Crash with no Debug Info

Question

I have a backup program that is currently running in our Corporate Environment on about 70 machines. A mixture of Laptops, Desktops and Windows (xp-32, vista-32, vista-64, 7-32-7-64) with no problems.

There is one exception, and it's the reason I'm posting here for assistance.

On one machine that is a Dell Latitude running Windows 7 64 bit with .Net 4 Framework installed the console application will crash immediately before it starts Sub Main. It simply give the generic windows error "A problem caused the program to stop working correctly." with no option to see debug info.

Things I have tried:
- Uninstalling all unstandard software
- Commenting out several declarations which I thought could cause issues
- Recompiled for Auto CPU , x86, and x64 to see if it made a difference
- Disabled the Virus Scanner
- User is an Administrator but I tried to run as Administrator
- Added a messagebox as the first thing in Sub Main to determine where it crashes
- Added try catches to all relevant code

I was able to get a bit more information from the Event Viewer:

Faulting Module Name: KERNELBASE.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdbdf
Exception Code: 0xe0434f4d Fault offset: 0x0000b727

These next few entries seem strange to me:

Faulting process id: 0x%9
Faulting application start time: 0x%10
Faulting application path: %11
Faulting Module path: %12

I also was able to pull up the .wer file (Windows Error Report Flat File) and it regurgitated most of the same info but also included some loaded dll and other files being used.

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

Joshua

edit:

I'm thinking of the following Win32 API calls might be causing the issues and they were the only things I couldn't easily comment out without a large code re-write.

If they are, why only on this one 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

first I would check out Tess Ferrdandez blog it has information on creating a crash debug file and looking at it with windbg

second I would attempt to repair the framework on one of these machines as we had a similar issue in a deployment and that resolved the problem.

Answer 2

I would change all your references for handles (hwnd) to IntPtr as this datatype will work in any .net framework but I don't believe the integer datatype will work in the 64 bit environment for handle handle.

The below is also sniipet from a Microsft article:

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

Structures that contain members that change size depending on the platform, such as any pointer type.

Pointer arithmetic that includes constant sizes.

Incorrect platform invoke or COM declarations that use Integer for handles instead of IntPtr.

Casting IntPtr to Integer.

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

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