.NET Application Crash with no Debug Info

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开发者_Python百科.

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

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.

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

Look at the fusion log to look at the assemblies its loading. Possibly not finding an assembly its trying to load.

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

EDIT: Wild shot in the dark ... Does this machine have Fast User switching enabled? If so, try disabling.

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

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