I have a c++ program compiled with MinGW which links to libmicrohttpd to run a webserver. It normally functions correctly, but I am trying to do some robustness testing and for my current test I have tried to disable the network interface. This results in the program crashing with the dialog box: "MyProgram.exe has stopped working - A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available."
Rather than debug the program and potentially its dependencies, for my purposes, it would be fine if it would just crash silently without making the dialog box (I have another component that is meant to restart it). Is this possible to do via some sort of manifest or Windows API call?
It turns out there is a Windows API function called SetErrorMode. Passing the parameter SEM_NOGPFAULTERRORBOX will prevent the error dialog from being displayed on a crash.
There is also the RegisterApplicationRestart function which can be used to have Windows restart an application in the event of a crash (or other configurable reasons).
We are facing the following issue:
The architecture is as follows:
A c++ native client application is connected to a native c++ server application via pipe RPC based on a IDL file.
I'm not particular savvy in this domain and havent coded the relevant parts but it works since a long time.
Since some days, one of our client-server tests fails.
Examining the issue shows that there is an exception in the very low-level RPC communication part:
Exception thrown at 0x00007FFF2649A388 (KernelBase.dll) in application.exe: 0x000006F7: The stub received bad data. occurred
The stack contains calls to functions in rpcrt4.dll.
Now the thing is we don't have any recent modifications in these parts of the code.
Neither in the functions on the client involved in that particular server RPC call.
Also, the same error occurs on my dev machine also with an older version of the code (for which the tests passed fine when this older version was tested on the test machines).
So i suspect some external issue, like updates to the windows libraries or such.
Did anyone encounter this error out of a sudden?
How should i go forward to debug and pinpoint the issue?
What i have done so far:
Debugged the client and server, and i see the call coming in on the server and the function executes fine.
It is when the result is being sent back to the client when the exception is fired on the client.
This is on Windows 10 x64, developed with Visual C++ 2017.
This is quite strange question, but, I believe, this is on-topic for SO.
Intro:
I have an service, written in C#, which calls my C++ library. C++ library execute some 3rdparty software via WinExec.
3rdparty software injects DLL via CreateRemoteThread. I don't have source files for this software.
Main part
I have 2 PCs - Win2008 and Win10.
For Win10 - this frankenstein is working flawlessly, Service runs DLL, DLL runs 3rdparty DLL injector, DLL injector injects stuff.
For Win2008 things are different. If I run 3rdparty DLL injector from CMD - it works flawlessly. But if I run service - Injector returns, that he got ERROR_NOT_ENOUGH_MEMORY from CreateRemoteThread.
Service is working from LocalService account, and everything is OK on Windows 10. I am looking for possible ideas\clues, why there is a problem with SERVICE (remember, CMD works fine) and ONLY for Windows 2008.
This issue might be related to creating a remote thread across privilege levels, as explained in the following blog article:
Injecting Code Into Privileged Win32 Processes
With XP SP2 and later (2003, Vista) some new security measures prevent the traditional CreateRemoteThread() function from working properly. You should be able to open the process, allocate memory on its heap, and write data to the allocated region, but when trying to invoke the remote thread, it will fail with ERROR_NOT_ENOUGH_MEMORY.
...
For XP SP2 I did a little debugging and found that inside CreateRemoteThread(), there is a call to ZwCreateThread() which is an export from ntdll.dll. The call is made while specifying that the thread should start suspended, which it does properly, however down the road still inside CreateRemoteThread() before ZwResumeThread() is called, there is a call to CsrClientCallServer() which fails and eventually leads to the error message.
The article explains some different ways of injecting remote threads on different version of Windows to avoid the error, ending with this conclusion:
At this point, we can successfully execute remote threads into privileged processes across all target platforms, but as mentioned before, its pretty messy. We're using three different, largely undocumented functions and auto-detecting which one to use based on the OS version.
The better solution is to create a secondary program that adds a service object (your injector program) to the service control manager database on the target system. Since you're administrator, which is required anyway, you'll be able to add these entries and start the service. This will enable the injector program to run with different access rights than normal code, and the traditional CreateRemoteThread() will work properly on Windows 2000, all of XP, and 2003/Vista. The API functions for adding and controlling the service are documented by MSDN and remain consistent across all of the platforms.
So, what is learned is that we can use a number of different functions to inject code into privileged remote processes, including RtlCreateUserThread() on XP SP2, and NtCreateThreadEx() on Vista, but the optimal way is to install a temporary service and allow CreateRemoteThread() to be the single API that accomplishes the task for all platforms.
Of course, none of this really matters since you don't have the source code for the injector and thus cannot change how it works.
Also, you can't create remote threads across session boundaries, either. Calling WinExec() in a service will run the injector process in the same session as the service, ie session 0. If it is trying to inject into a process that is running in a user session, that will never work. This would also explain why running the injector from CMD works, if CMD is running in the same session as the process that is being injected into.
I encountered the same issue today and this seems to be the issue-
Prior to Windows 8, Terminal Services isolates each terminal session by design. Therefore, CreateRemoteThread fails if the target process is in a different session than the calling process.
This explains why your code works on Windows 10 but not on Windows 7/2008.
Source: https://msdn.microsoft.com/en-us/library/windows/desktop/dd405484(v=vs.85).aspx
I am VC and VC++ developer. I use VS2008.I have developed an API for capturing the fingerprint through a biometric scanner, in VC. After capturing the fingerprint, I need to display the fingerprint image to the user. So I used DialogBoxParam()method to create a GUI. I have 3 modules. First is the Core DLL, Second is the Windows Service and the Third is Scanner DLL. For capturing the fingerprint, I used to give request from core DLL to the service the will contact the Scanner and revert us back. After the response from the service I call DialogBoxParam() method to show the fingerprint GUI. I have used GetForegroundWindow() to bring the GUI to the front of the browser. In Windows 7, IE 9 or above, the DialogBoxParam() method gets failed. If I avoid GetForegroundWindow(), DialogBoxParam() method got succeeded. I cannot find the solution for this problem. Please help me in this. Below is the code to create the GUI.
*
DialogBoxParam(GetInstance(),MAKEINTRESOURCE(IDD_FEATURE_DIALOG),GetForegroundWindow(),(DLGPROC)WndProc,
NULL);
*
DialogBoxParam return -1 and GetLastError return 0 in ActiveX Control
We have a unmanaged C++ TCP server application running as a Windows service that is silently crashing after few days of run on Win2003 server. There is no Dr. Watson log file getting generated (no issue with Dr. Watson log as it catches other crashes in same application). Due to lack of Dr. Watson log file, we are unable to progress on how to debug this further..
The TCP server application is sort of HTTP processor. It connects to wide range of webserver and processes data.
Can someone please guide me what can be done to debug the silent crashes.. There are 1000+ users connected to this server at any instant and thus its not possible to run the same in debug mode. The crash is not reproducible and happens once in 5-10 days on one of the 6 servers..
Any tool that can help to debug these silent crashes. The application is a pure C++ application without any MFC or STL..
Thanks in Advance.
Krishna
The last time I had a silent crash problem like this, it was because of C runtime parameter validation., which by default just calls TerminateProcess without any other goodness (depending on which version of msvcrt*.dll you link to). If this is the cause of your problem, you can avoid it by calling _set_invalid_parameter_handler and giving a handler that either calls DebugBreak (forcing a crash) or does nothing, allowing an error code to be returned to the caller. Details in the link above.