hi i have been using Visula studio 2008 i was able to build the code and while debugging my project in release mode i am getting this error
how to get rid of this "Native' has exited with code 1 (0x1)" Error
lst_0704.exe': Loaded 'C:\lst\bin\lst_0704.exe', Symbols loaded.
lst_0704.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll'
lst_0704.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll'
lst_0704.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll'
The program '[6480] lst_0704.exe: Native' has exited with code 1 (0x1).
i have tried to change my project to debug mode as suggested in one of MSDN blogs but i am still getting this error
will there be any issue with command line arguments given in project properties?
This line does not necessarily indicate an error:
The program '[6480] lst_0704.exe: Native' has exited with code 1 (0x1).
It just means that your program's process (lst_0704.exe) has exited, presumably because you asked it to do so. The "native" part means that your application is compiled to native code, as opposed to managed code. And it's also telling you that the return code was 1.
Traditionally, when an application exits normally without any errors, it will return a code of 0. But that is not strictly required. There is really nothing in the operating system itself that checks these return codes—it is up to you to do so if you care.
I can't tell you exactly why your application is returning a code of 1 on exit, because you haven't posted any of your code. But my psychic powers tell me that there is probably a return 1; statement (or its functional equivalent) at the end of your main method. If you want the application to exit with a return code of 0, you'll need to change that to return 0;.
In Windows applications (as opposed to Console applications), the return code is typically the wParam of the WM_QUIT message that causes the application to terminate. In other words, the main message loop will look something like this:
MSG msg;
BOOL bRet;
while ((bRet = GetMessage(&msg, NULL, 0, 0)) != 0)
{
if (bRet == -1)
{
// An error occurred
}
else
{
// Process the message
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
// GetMessage returned WM_QUIT, so return the exit code.
return msg.wParam;
You cause the generation of the WM_QUIT message by calling the PostQuitMessage function, which takes a single parameter that specifies the exit code. That is the one that gets passed as the wParam and returned as the process's exit code. Again, it does not matter what code you return here, but it is traditionally 0 if the code is exiting normally with no errors.
This exact error, but with a different underlying cause, was preventing me from starting execution of a new project. There were no other errors, exceptions, or any other indications about what was wrong.
My cause turned out to be due to creating the project as a console application, then switching it to a Windows application. The startup code is different and incompatible between the two types of projects. Replacing Program.cs with its static Main() method and modifying its namespaces, etc., from another project created as a Windows application resolved my error.
I hope this helps someone else who is confused by this unhelpful error message.
Related
Situation:
We have an MFC/C++ Visual Studio (2005) application consisting of a lot of executables and a lot of dlls, all using MFC and interconnected with DCOM. Some are running on a controller (w2012) which controls slave computers running on WES2009.
The problem:
For diagnostic purposes we are embedding minidumps in all of our processes. This mechanism works fine in all processes except for one: the GUI exe. All processes including the GUI make dmp files BUT the dmp file contents of the GUI seems to be different/wrong. When I intentionally crash our application with e.g. a null pointer dereference, all dmp files of all processes/dlls (except GUI) point to the cause (the null pointer dereference)! The dmp file of the GUI process is created and can be openend in Visual Studio but non of the threads point to the cause (the null pointer dereference). Also windbg does not find the cause! The strange thing is that when we manually use WriteStackDetails() to dump the callstack it returns the correct problematic line! So why can't MinidumpWriteDump() do the same for only this one process? What could be the discriminating factor? Anyone any idea?
What we tried:
We tried crashes in all other process and dlls and they all seem to work ok except the GUI process! Unicode / non-Unicode does not seem to matter. A seperate test application works well, also when I link our production code library which contains the UnhandledExceptionFilter() and MinidumpWriteDump(). Crashes in sub(-sub) dlls does not seem to matter. The project settings wrt exception handling appear to be all the same. Anyone any idea?
Some more info and remarks:
Our production code (controller and slaves) is running in separate virtual boxes for development purposes.
yes we understand that the minidump should ideally be created from another process (some example somewhere? wrt process querying and security?) but doing it in-process seems to work 'always ok' for now. So we accept the risk for now that it might hang in rare situations.
What I mean with the dmp file contents is different/wrong is the following:
For our non-GUI exe we get the following OK thread / callstack information:
0xC0000005: Access violation reading location 0x00000000.
Studio automatically opens the correct source and the "breakpoint" is set to the faulty line of code.
In the Call stack tab I see my own functions in my own dll which has caused the crash: my null pointer dereference.
In the Threads tab I also see my active thread and Location which points also to the faulty function which crashed.
So all is fine and usable in this situation! Super handy functionality!
For our GUI exe, which links to the same production library code wrt MinidumpWriteDump() and ExceptionHandlingFiler() code, we get the following NOK thread / callstack information:
Unhandled exception at 0x77d66e29 (ntdll.dll) in our_exe_pid_2816_tid_2820_crash.dmp: 0xC0150010: The activation context being deactivated is not active for the current thread of execution
Visual Studio 2005 does not show my faulty code as being the cause!
In the Call stack tab I don't see my own faulty function.
The Call stack tab shows that the problem is in ntdll.dll!RtlDeactivateActivationContextUnsafeFast()
The top most function call which is shown of our code is in a totally different gui helper dll, which is not related to my intentionally introduced crash!
The Threads tab also shows the same.
For both situations I use the same visual studio 2005 (running on w7) with the same settings for symbol paths!!! Also visual studio 2017 cannot analyze the 'wrong' dmp files. In between of both test above, there is no rebuild so no mismatch occurs between exe/dlls and pdbs. In one situation it works fine and in another not!?!
The stripped-down-to-essentials code we use is shown below
typedef BOOL (_stdcall *tMiniDumpWriteDump)(HANDLE hProcess, DWORD dwPid, HANDLE hFile,
MINIDUMP_TYPE DumpType, CONST PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
CONST PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
CONST PMINIDUMP_CALLBACK_INFORMATION CallbackParam);
TCHAR CCrashReporter::s_szLogFileNameDmp[MAX_PATH];
CRITICAL_SECTION CCrashReporter::s_csGuard;
LPTOP_LEVEL_EXCEPTION_FILTER CCrashReporter::s_previousFilter = 0;
HMODULE CCrashReporter::s_hDbgHelp = 0;
tMiniDumpWriteDump CCrashReporter::s_fpMiniDumpWriteDump = 0;
CCrashReporter::CCrashReporter()
{
LoadDBGHELP();
s_previousFilter = ::SetUnhandledExceptionFilter(UnhandledExceptionFilter);
::InitializeCriticalSection(&s_csGuard);
}
CCrashReporter::~CCrashReporter()
{
::SetUnhandledExceptionFilter(s_previousFilter);
...
if (0 != s_hDbgHelp)
{
FreeLibrary(s_hDbgHelp);
}
::DeleteCriticalSection(&s_csGuard);
}
LONG WINAPI CCrashReporter::UnhandledExceptionFilter(PEXCEPTION_POINTERS pExceptionInfo)
{
::EnterCriticalSection(&s_csGuard);
...
GenerateMinidump(pExceptionInfo, s_szLogFileNameDmp);
::LeaveCriticalSection(&s_csGuard);
return EXCEPTION_EXECUTE_HANDLER;
}
void CCrashReporter::LoadDBGHELP()
{
/* ... search for dbghelp.dll code ... */
s_hDbgHelp = ::LoadLibrary(strDBGHELP_FILENAME);
if (0 == s_hDbgHelp)
{
/* ... report error ... */
}
if (0 != s_hDbgHelp)
{
...
s_fpMiniDumpWriteDump = (tMiniDumpWriteDump)GetProcAddress(s_hDbgHelp, "MiniDumpWriteDump");
if (!s_fpMiniDumpWriteDump)
{
FreeLibrary(s_hDbgHelp);
}
else
{
/* ... log ok ... */
}
}
}
void CCrashReporter::GenerateMinidump(const PEXCEPTION_POINTERS pExceptionInfo,
LPCTSTR pszLogFileNameDmp)
{
HANDLE hReportFileDmp(::CreateFile(pszLogFileNameDmp, GENERIC_WRITE, 0, 0,
CREATE_ALWAYS, FILE_FLAG_WRITE_THROUGH, 0));
if (INVALID_HANDLE_VALUE != hReportFileDmp)
{
MINIDUMP_EXCEPTION_INFORMATION stMDEI;
stMDEI.ThreadId = ::GetCurrentThreadId();
stMDEI.ExceptionPointers = pExceptionInfo;
stMDEI.ClientPointers = TRUE;
if(!s_fpMiniDumpWriteDump(::GetCurrentProcess(), ::GetCurrentProcessId(),
hReportFileDmp, MiniDumpWithIndirectlyReferencedMemory,
&stMDEI, 0, 0))
{
/* ... report error ...*/
}
else
{
/* ... report ok ... */
}
::CloseHandle(hReportFileDmp);
}
else
{
/* ... report error ...*/
}
}
Below is a code snippet where I deliberately cause 2 NullPointerException. The first one is handled. Whereas the second one goes unhandled. I want to create a crash dump on the second exception when a crash would occur.
int* nullPtr = NULL;
try{
x = *nullPtr;
}
catch(...) {
QLOG_WARNING0(QTEXT("catching 1st null ptr exception."));
}
y = *nullPtr;
This does crash the process but the dump is not generated using -e option only.
What options should I use to get the dump?
Or is there a way I could achieve this with debugDiag tool? If so, how?
This is only a sample code. The actual use case I am debugging has a process crashing but I am unable to take dumps for the crash. There are valid handled exceptions where the dump is getting triggerred in case I use the first chance option( - e 1). This is causing procdump to exit before the actual crash occurs.
“No I am open to any other tool.”
Per your comment, there are other ways to trap a dump file. In my answer to Getting detailed crash dumps from a hooked exe,
you’ll see that you can set some registry key settings to trap the dump from an unhandled exception. The settings assume you have Windows Error Reporting enabled. I’ve gone so far as to incorporate those settings into a small utility program that my company uses when debugging difficult customer crashes.
I'm working on an utility that processes very large data sets. Since there are lots of code it uses to operate, some totally unexpected errors appear while running. So I run it inside Visual Studio debugging session. In most cases I can skip an error or recover from it using immediate window and some manipulation with "Set next statement". But this error can reoccur in future. Is it possible to automatize recovering process without restarting debugging session?
Depending on the structure of your code and the language you are using you may be able to do something similar with Conditional Breakpoint abuse.
The idea is to use the Breakpoint condition to do an evaluation, basically an automated way of doing what you do in the immediate window.
int c = a + b; // some type of calculation
if (c == 5) // your test
{
// ERROR
return;
}
E.g. If you know the test c==5 is what is going wrong you can place a Conditional Breakpoint at that line:
if (c == 5) // your test
With the expression of some correct value:
c = 1
And then you won't go down the error condition path. Of course this doesn't always work, but can be useful in come circumstances.
How can I obtain the JVM exit code (value of 'status' from call: System.exit(status)) from a Windows program which started this JVM? I tried to use result from the ShellExecute() call, but the result (42) was independent of real value of status.
Start the external application by using ShellExecuteEx instead of ShellExecute.
Before calling ShellExecuteEx, enable the SEE_MASK_NOCLOSEPROCESS flag in the parameter to the ShellExecuteEx function. You will then receive a handle to the started process in the hProcess field of the parameter to the ShellExecuteEx function.
ShellExecuteEx: http://msdn.microsoft.com/en-us/library/bb762154(VS.85).aspx
Then, use the WaitForSingleObject function or any other WaitFor* function to wait until the external application is terminated.
WaitForSingleObject: http://msdn.microsoft.com/en-us/library/ms687032.aspx
Then, use the GetExitCodeProcess function to read the exit code of the external process.
GetExitCodeProcess: http://msdn.microsoft.com/en-us/library/ms683189(VS.85).aspx
The MSDN docs for that function make it quite clear that it does not return the exit codes from the called application.
If the function succeeds, it returns a
value greater than 32. If the function
fails, it returns an error value that
indicates the cause of the failure.
The return value is cast as an
HINSTANCE for backward compatibility
with 16-bit Windows applications. It
is not a true HINSTANCE, however. It
can be cast only to an int and
compared to either 32 or the following
error codes below.
There appears to be some example code for getting exit status at MSDN as well.
I have a DLL that's loaded into a 3rd party parent process as an extension. From this DLL I instantiate external processes (my own) by using CreateProcess API. This works great in 99.999% of the cases but sometimes this suddenly fails and stops working permanently (maybe a restart of the parent process would solve this but this is undesirable and I don't want to recommend that until I solve the problem.) The failure is symptomized by external process not being invoked any more even though CreteProcess() doesn't report an error and by GetExitCodeProcess() returning 128. Here's the simplified version of what I'm doing:
STARTUPINFO si;
ZeroMemory(&si, sizeof(si));
si.cb = sizeof(si);
si.dwFlags = STARTF_USESHOWWINDOW;
si.wShowWindow = SW_HIDE;
PROCESS_INFORMATION pi;
ZeroMemory(&pi, sizeof(pi));
if(!CreateProcess(
NULL, // No module name (use command line).
"<my command line>",
NULL, // Process handle not inheritable.
NULL, // Thread handle not inheritable.
FALSE, // Set handle inheritance to FALSE.
CREATE_SUSPENDED, // Create suspended.
NULL, // Use parent's environment block.
NULL, // Use parent's starting directory.
&si, // Pointer to STARTUPINFO structure.
&pi)) // Pointer to PROCESS_INFORMATION structure.
{
// Handle error.
}
else
{
// Do something.
// Resume the external process thread.
DWORD resumeThreadResult = ResumeThread(pi.hThread);
// ResumeThread() returns 1 which is OK
// (it means that the thread was suspended but then restarted)
// Wait for the external process to finish.
DWORD waitForSingelObjectResult = WaitForSingleObject(pi.hProcess, INFINITE);
// WaitForSingleObject() returns 0 which is OK.
// Get the exit code of the external process.
DWORD exitCode;
if(!GetExitCodeProcess(pi.hProcess, &exitCode))
{
// Handle error.
}
else
{
// There is no error but exitCode is 128, a value that
// doesn't exist in the external process (and even if it
// existed it doesn't matter as it isn't being invoked any more)
// Error code 128 is ERROR_WAIT_NO_CHILDREN which would make some
// sense *if* GetExitCodeProcess() returned FALSE and then I were to
// get ERROR_WAIT_NO_CHILDREN with GetLastError()
}
// PROCESS_INFORMATION handles for process and thread are closed.
}
External process can be manually invoked from Windows Explorer or command line and it starts just fine on its own. Invoked like that it, before doing any real work, creates a log file and logs some information about it. But invoked like described above this logging information doesn't appear at all so I'm assuming that the main thread of the external process never enters main() (I'm testing that assumption now.)
There is at least one thing I could do to try to circumvent the problem (not start the thread suspended) but I would first like to understand the root of the failure first. Does anyone has any idea what could cause this and how to fix it?
Quoting from the MSDN article on GetExitCodeProcess:
The following termination statuses can be returned if the process has terminated:
The exit value specified in the
ExitProcess or TerminateProcess
function
The return value from the
main or WinMain function of the
process
The exception value for an
unhandled exception that caused the
process to terminate
Given the scenario you described, I think the most likely cause ist the third: An unhandled exception. Have a look at the source of the processes you create.
Have a look at Desktop Heap memory.
Essentially the desktop heap issue comes down to exhausted resources (eg starting too many processes). When your app runs out of these resources, one of the symptoms is that you won't be able to start a new process, and the call to CreateProcess will fail with code 128.
Note that the context you run in also has some effect. For example, running as a service, you will run out of desktop heap much faster than if you're testing your code in a console app.
This post has a lot of good information about desktop heap
Microsoft Support also has some useful information.
There are 2 issues that i could think of from your code sample
1.Get yourusage of the first 2 paramaters to the creatprocess command working first. Hard code the paths and invoke notepad.exe and see if that comes up. keep tweaking this until you have notepad running.
2.Contrary to your comment, If you have passed the currentdirectory parameter for the new process as NULL, it will use the current working directory of the process to start the new process from and not the parent' starting directory.
I assume that your external process exe cannot start properly due to dll dependencies that cannot be resolved in the new path.
ps : In the debugger watch for #err,hr which will tell you the explanation for the last error code,