I'm getting this exception: System.BadImageFormatException was unhandled whenever I try to run a program compiled on my PC. I'm running the Okuma PC Sim software on my laptop.
This happens even if I open and compile the API Test app that ships with the API.
Below are the exception details:
System.BadImageFormatException was unhandled
Message= is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)
Source=thincLathe
StackTrace:
at thincLathe.frmMain.Form1_Load(Object sender, EventArgs e)
at System.Windows.Forms.Form.OnLoad(EventArgs e)
at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
at System.Windows.Forms.Control.CreateControl()
at System.Windows.Forms.Control.WmShowWindow(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Please reference http://support.microsoft.com/kb/967163
Long KB short... change your compile settings in VS. The "ANYCPU" setting should be changed to match the target system, x86 or x64.
Related
I am making a dll file and at the same time trying to call this function automatically when my DLL is loaded. How can I do this? It is a Windows API main function that creates a window but I dont know how do it. My first idea is to put it into DllMain function but I am really sure if this will work and also what to fill in the variables "HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow"
Below is the function I am trying to call automatically when my dll is loaded and I expect it to open a Window. Thanks.
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,LPSTR lpCmdLine, int nCmdShow);
There are limitations on what you can do in a DllMain function:
Calling functions that require DLLs other than Kernel32.dll may result in problems that are difficult to diagnose. For example, calling User, Shell, and COM functions can cause access violation errors, because some functions load other system components.
That rules out creating a window directly from DllMain. What you can do, however, is launch a thread from your DllMain, and that thread can create a window.
DLLs do have a WinMain() function. DllMain() or DllEntryPoint() are what you are looking for. Windows itself calls them when the DLL is loaded and unloaded. You do not call them yourself, you implement them instead. As for creating a window, you call CreateWindow/Ex() and related functions.
Is it possible to crash a regular user-mode process on Windows-7 without getting the Windows Error Reporting (WER) dialog? (When and if WER is normally enabled and no specific flags are applied.)
Note: I'm not interested in disabling WER, I'm interested in crash scenarios where WER isn't launched although it should and Windows "silently" terminates an app.
On Windows XP, it is pretty trivial to write a C or C++ application (in user mode) that messes up its own address space in such a way that when an Access Violation (or other unhandled Win32 Exception) is finally raised, Windows XP will just silently terminate the process without informing the user at all:
...
void stackbreaker() {
printf("%s\n", __FUNCTION__);
// global/static buffer
static char buf[128] = "In a hole in the ground there lived a hobbit. And it burrowed through your stack. It even built a round door into you function.";
// Get address on the stack
char local;
char* stack = &local;
// nuke the stack:
memcpy(stack - 64, buf, sizeof(buf));
// Kaboom. No user defined unhandled exception filter will be called. Stack nuked.
// Process will terminate silently on Windows XP.
// But on Windows-7 you still get the WER dialog.
}
...
Calling the above function in a simple C++ project (in release mode -- watch out for those compiler optimizations when testing -- and not run under the debugger) will:
Silently terminate the process, under XP.
Display the WER crash dialog under Windows-7.
Aside: In no circumstance will it call your own unhandled exception filter, even if you set one via SetUnhandledExceptionFilter
What I am wondering now is whether - under Windows 7 - the WER mechanism has been implemented in a way that I always get an error dialog for a crash[a] in my application, or whether there exist process corruption scenarios even in Windows 7, that will prevent the WER dialog from popping up?
I'll add a bit of the reading up I did:
In the book Windows via C/C++ (5th ed by Richter, Nasarre) they describe what happens in a "Faulting Process" (p 711):
Exception filters.
...
...
kernel detects unhandled exception
blocking ALPC call to Wer Service
WER reporting kicks in.
...
Now, they point here is that Win7 does this differently than Windows XP (to quote this book p. 710:)
... Starting with Windows Vista, the UnhandledExceptionFilter function no longer sends an error report to MS' servers. Instead. The kernel detects that the exception is not handled by the user-mode thread (Step 4)...
So this would imply, that there is no way at all for a process to "crash" -- in Vista and above -- in a way that prevents WER kicking in. I'm trying to either confirm or refute this.
[a]: Obviously, a process can easily be "killed" without any trace by calling one of the various *exit or terminate* functions. The question is, if you can rule out such a termination reason, (how) is it possible to "crash" a user-mode process on Win7 in a way that would prevent the WER dialog from being displayed.
I took a look at my edition of Windows Internals, but it doesn't have a whole lot to say on the subject. In earlier versions, the windows error reporting routine took place in the context of the crashing thread. This means that if the stack is trashed (as in your example), it might not be able to run.
In Vista and later, it runs externally to the crashing thread. In addition, the kernel itself is responsible for notifying WER when a process crashes (through an advanced local procedure call).
According to Windows Internals, these changes fix the vanishing process problem. I can only take their word for that. Obviously, if the WER service is itself damaged (or stopped), you'll still get silent crashes.
EDIT
From Windows Internals, 5th Edition, page 122:
Until Windows Vista, all the [WER] operations we've described had to occur within the crashing thread's context... In certain types of crashes ... the unhandled exception filter itself crashed. This "silent process death" was not logged anywhere. ... Windows Vista and later versions improved the WER mechanism by performing this work externally from the crashed thread, if the unhandled exception filter itself crashes.
Page 124:
...all Windows processes now have an error port that is actually an ALPC port object registered by the WER service. The kernel ... will use this port to send a message to the WER service, which will then analyze the crashing process. ... This solves all the problems of silent process death...
You already know how to crash a process, so I answer regarding hiding the WER dialog.
Way to hide WER dialog since Windows XP:
UINT WINAPI SetErrorMode(_In_ UINT uMode);
SEM_NOGPFAULTERRORBOX
0x0002 The system does not display the Windows Error Reporting dialog.
Note that there are also other reasons for error dialogs and they can be disabled with this function too, check the documentation for more info.
Additionally since Windows 7:
BOOL SetThreadErrorMode(
_In_ DWORD dwNewMode,
_Out_ LPDWORD lpOldMode
);
Some programs and dll-s use these functions to hide errors from the user.
I Implemented file dropping based on a drop target class sample from catch22.net. Everything works fine on 32-Bit - but nothing works in my x64-Bit version.
HRESULT __stdcall CDropTarget::QueryInterface (REFIID iid, void ** ppvObject)
is not called when calling
pDropTarget = new CDropTarget(hwnd);
CoLockObjectExternal(myDropTarget, TRUE, FALSE);
as it is in the 32-Bit version. The problem occurs on XP and Windows 7. I am using VS 2010.
Whats the problem?
Many times when I change VPN status by disconnecting a remote network my VS instance immediately crashes.
This is the closest thing I can find in the event log. Anyone have any ideas about this?
Exception: System.Net.NetworkInformation.NetworkInformationException
Message: Invalid access to memory location
StackTrace: at System.Net.NetworkInformation.SystemNetworkInterface.GetAdaptersAddresses(AddressFamily family, FixedInfo fixedInfo)
at System.Net.NetworkInformation.SystemNetworkInterface.PostWin2KGetNetworkInterfaces(AddressFamily family)
at System.Net.NetworkInformation.SystemNetworkInterface.GetNetworkInterfaces(AddressFamily family)
at System.Net.NetworkInformation.SystemNetworkInterface.InternalGetIsNetworkAvailable()
at System.Net.NetworkInformation.NetworkChange.AvailabilityChangeListener.ChangedAddress(Object sender, EventArgs eventArgs)
at System.Net.NetworkInformation.NetworkChange.AddressChangeListener.AddressChangedCallback(Object stateObject, Boolean signaled)
at System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(Object state, Boolean timedOut)
I got this exception when running my 32 bit application (which was built with /LARGEADDRESSAWARE enabled) on Windows 7 from time to time. While trying to find the problem I came across a hotfix that appears to fix the issue.
Try the following hotfix and see if that fixes it for you: http://support.microsoft.com/kb/2588507
private void button1_Click(object sender, EventArgs e)
{
///IDE will notify me of this exception
throw new Exception();
}
private void Form1_Load(object sender, EventArgs e)
{
//IDE will not notify me of this exception
throw new Exception();
//code will not execute
MessageBox.Show("test");
}
why?
----------------------EDITED----------------------
the correct answer is what ChrisA mentioned.
some quotes from microsoft :
This is a known bug with x64 versions
of Windows and the way exceptions are
handled. One way to work around this
issue while debugging is to go to the
Debug -> Exceptions and select
'Thrown' for for the exception types
you are interested in. This will stop
the debugger when the exception is
first hit (and before Windows eats it
up).
This bug was closed as "External"
because this behavior results from how
x64 version of Windows handle
exceptions. When a user mode exception
crosses a kernel transition, x64
versions of Windows do not allow the
exception to propagate. Therefore
attached debuggers are unaware of the
fact that an exception occured
resulting in the debugger failing to
break on the unhandled exception.
Unfortunately where is nothing that
the Visual Studo team can do to
address this, it is the result of
operating system design. All feedback
regarding this issue should be
addressed to the Windows team; however
the Windows team considers this to be
the "correct" operating system design,
and considers the x86 behavior to be
"incorrect".
This hotfix has not undergone full
testing. Therefore, it is intended
only for systems or computers that are
experiencing the exact problem that is
described in the one or more Microsoft
Knowledge Base articles that are
listed in "KB Article Numbers" field
in the table at the end of this e-mail
message. If you are not sure whether
any special compatibility or
installation issues are associated
with this hotfix, we encourage you to
wait for the next service pack
release. The service pack will include
a fully tested version of this fix. We
understand that it can be difficult to
determine whether any compatibility or
installation issues are associated
with a hotfix. If you want
confirmation that this hotfix
addresses your specific problem, or if
you want to confirm whether any
special compatibility or installation
issues are associated with this
hotfix, support professionals in
Customer Support Services can help you
with that.
Are you developing on an x64 machine?
If so, you might like to have a look at this.
That thread also refers to a very detailed explanation of the whole issue.
This, and another show stopper (for me anyway, the workarounds didn't work for me, or my colleague) on x64, resulted in a rebuild of my dev box with win7 x86.
The problems have all gone away now. But it's very disappointing.