Windows Service Error:
Error 1053: The service did not respond to the start or control request in a timely fashion
Event Log Error Recorded:
Faulting application [applicationname].exe, version 0.0.0.0, time stamp 0x541e3f33, faulting module unknown, version 0.0.0.0, time stamp 0x00000000, exception code 0xc0000005, fault offset 0x00000000, process id 0x12c, application start time 0x01cfd54841eed684.
Libraries used:
Several Boost(1.55.0) Libraries: chrono, date_time, filesystem, iostreams, log, system, thread, zlib
OpenSSL(1.0.1i): libeay32.dll, ssleay32.dll
ZMQ: libzmq.dll, czmq.dll
When run as LocalSystem Privilege:
The same application works without any problem in Windows Server 2003,
but on Window Server 2008, it crashes instantly.
When run as Administrator, it's work in both 2003 and 2008 server.
How do I debug this problem?
I don't think there is any problem with the code, coz if there was, I wouldn't have been able to run it in my local (Windows8) and Windows server 2003.
Here is the code for reference anyway.
http://pastebin.com/zxh52Xdm
Related
I'm trying to run a Qt d-bus example (chat) on Windows. It compiles fine but I get this error:
Cannot connect to the D-Bus session bus. Please check your system
settings and try again. QEventDispatcherWin32::wakeUp: Failed to post
a message
I installed D-Bus on Windows through a ready made installer found in Google archives.
Can someone give me an idea how to run dbus-daemon on Windows?
I have a Jetty 9 server embedded in my app and found that when I launch the program in eclipse and then stop it via the eclipse red button, Jetty stays running in the background.
I have to do a netstat to find which process owns the port and then do a taskkill.
Now do I configure jetty to die when the host app dies?
The Server instance should be told to stop.
server.stop();
Jetty does not know about any host app, it runs on its own daemon thread.
You could also just use java.lang.System.exit(int) to close the JVM and all threads it has running.
Killing the JVM (via the Eclipse Red Button) should kill all threads on that JVM too. If it doesn't, you have discovered a bug in Eclipse.
But before you go there, you should know that Eclipse IDE itself has it's own Eclipse Jetty server running (used for a number of things internally, and also for serving the documentation / help page).
So just the fact that you see an Eclipse Jetty instance running is misleading, it could be the one that the Eclipse IDE itself is running for its own reasons.
I have an msi installer that installs two windows services. There are no errors during installation on a Windows Server 2016 64-bit machine, the installation succeeds but the services are not installed. I was able to install the services manually using installutil but there are no clues as to why the msi failed to install the services. The installer has worked so far in hundreds of installations. I was able to get the event logs from the machine and the only errors I was able to find are in the Application log are of the kind:
Faulting application name: MsiExec.exe, version: 5.0.14393.0, time
stamp: 0x57899002
Faulting module name: MSIC9AE.tmp, version: 4.0.30319.33440, time
stamp: 0x52004298
Exception code: 0xc0000005
Fault offset: 0x000064ff
Faulting process id: 0x2244
Faulting application start time: 0x01d3db09c12691f2
Faulting application path: C:\Windows\syswow64\MsiExec.exe
Faulting module path: C:\Windows\Installer\MSIC9AE.tmp
Report Id: c5ffdc35-5ccd-4b00-9d60-1a198848062e
Faulting package full name:
Faulting package-relative application ID:
Installing again with verbose logging is not an option.
Any help is greatly appreciated.
There isn't much information on how you are installing the services, or what tool you are using to generate the MSI and install those services, but I can make some guesses from that log:
It appears that you are using installer class custom actions to install the services. In every case I'm aware of (except Visual Studio setups) this is unnecessary. Windows Installer has built-in support for installing services without running any code. Custom actions (instead of standard built-in functionality) are error prone. The better tools provide support for the ServiceInstall table and the ServiceControl table and that gets you out of the need to run code and the related issues.
That log shows that you are running a 32-bit msiexec.exe process to install services on a 64-bit system. I believe the 32-bit subsystem is optional on Windows Server, but it's not clear if that's an issue because the install apparently succeeds, although installer class failures typically throw an error and completely roll back the install. Are you installing silently? The other issue could be that there is no 32-bit NET FW to run that (apparently) 32-bit custom action. Or there is a NET FW architecture mismatch (you have some NET 2 code attempting to run in the 4.0 runtime). If that error 0xC0000005 is to be trusted, then you have an access violation inside the custom action code - custom actions work by extracting the code from the MSI Binary table into a random name .tmp file and then calling it from an msiexec.exe process, so perhaps the custom action code has lost access to that \installer folder for some reason. There is also a C++ shim Dll that loads a framework to run the managed code, so there is room for a C++ dependency failure in there as well
The installer class custom action framework is really difficult to debug when it fails because there are plenty of failure points, which is why I pointed out that installer classes can be error-prone as well as unnecessary.
Windows requires different setups for different architectures, so for a 64-bit install it's worth making sure that all the custom action code is explicitly built for 64-bit, if the issue is cross-architecture related.
On the development server I use IIS Veresion 7.5.7600.16385
And a Service compiled for .Net 4.5.1, Any CPU
The service works fine on the development server (Win Server 2008 R2).
On the client's production server however I get strange problems:
(Same IIS Version, same OS version)
As soon as I set "Enable 32-Bit Applications" the service's URL is no longer accessible in a browser. (Page not available)
(I need the 32Bit mode because the service uses some legacy COM components)
What may cause this problems?
Any ideas, hints, suggestions?
Edit
More Details:
The "IIS Worker Process" is running as "w3wp.exe *32"
There is a ClickOnce Installation in the same Application Pool which behaves the same: works ok in 64 bit, not accessible if 32Bit set to true.
In fact all pages of this 32Bit App-Pool produce the same behaviour (HTTP 500) page not found.
Step 1: Enable Logging in IIS
In Order to enable better error messages and log files in IIS you must install two Features:
Control Panel->Programs and Features->Turn Windows features on or off
You'll need two features installed:
WebServer->Common Http Features->HTTP Errors
WebServer-> Health an Diagnostics->HTTP Logging
Step 2: Analyse Error Messages
With HTTP Errors enabled I got a more verbose message when I accessed any page in the 32Bit App Pool:
HTTP Error 500.19
DynamicCompressionModule
ErrorCode 0x8007007e
Step 3: Decode Error Code
I used Microsoft Exchange Server Error Code Look-up to convert the ErrorCode into something more useful:
C:\Users\combyte>err 0x8007007e
as an HRESULT: Severity: FAILURE (1), Facility: 0x7, Code 0x7e
...
ERROR_MOD_NOT_FOUND winerror.h
The specified module could not be found.
It turned out, that a specific DLL was not installed. In my case the installation of WSUS (Windows Server Update Services) installed a 64Bit version of DynamicCompressionModule (C:\Windows\system32\inetsrv\suscomp.dll) only.
Solution1
Remove/Disable the XPress compression scheme from the IIS configuration (for all pages/app-pools) using this command:
%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /-[name='xpress']
Solution2
Disable loading of the xpress module in IIS config file C:\Windows\System32\inetsrv\config\ApplicationHost.config for 32Bit App-Pools:
add attribute preCondition="bitness64" to the xpress module in section <modules>:
<add name="DynamicCompressionModule" lockItem="true" preCondition="bitness64" />
Solution3
Install the 32Bit version of suscomp.dll(from a 32 Bit Installation of WSUS) into %windir%\SYSWOW64\inetsrv\
I followed the steps in this link
and I manage to debug a binary which resides in linux host from my windows machine from command prompt.
I have gdbserver in linux and I installed gdb with the help of mingw in windows. As I told I can prompt "target remote x.x.x.x:10000 test" to command in windows and debug my test application.
My problem is I can't do the same with eclipse gui, it seems to me it has tones of buttons, options but they make no sense to me.
I am choosing debug_configurations-->C/C++ Remote Application(the only one which allows me to input linux machine ip/port), in "Main" tab to connection I am inputting my linux ip. In same menu under Debugger tab I am inputting my window's gdb path and gdbserver port.
After doing all those I believe I gave enough info to eclipse for connect gdb server but it never enough for eclipse. I am checking gdbserver logs by starting gdbserver with --debug, gdbserver never gets triggered, it does not writes a single line of log. Eclipse even does not starts a connection. But instead it gives me a error like "Error during file upload." which makes no sense to me.
I am using "Eclipse Version: Juno Service Release 2" . Any help will be appreciated .
I believe that the "C/C++ Remote Application" option uses Eclipse's RDT (Remote Development Tools) and RSE (Remote System Explorer) to connect, upload, execute, and debug the application itself. It
If all you want to do is connect to a gdbserver, then create a "C/C++ Attach to Application" debug configuration, and under the Debugger tab, set Debugger to gdbserver.
I also encountered this error message for other reason on Eclipse version 2019-09 R (4.13.0).
I very recommend to read paragraph "How do I debug a remote application?" from this great guide.
It explains which of three remote debugging options you should be using - Automatic Remote Launcher, Manual Remote Launcher and Remote Attach Launcher and how to use each one.
I was using the wrong launcher and hence got the error, while on the remote side gdbserver was listening and waiting for a connection. Switching to Manual Remote Launcher solved it.
for example it says:
If you don't have RSE installed, you cannot use the "Automatic Remote
Launch"
RSE = Remote System Explorer End-User Runtime
Launcher setting is configured from the bottom of the Remote Debug Configuration window - "Using GDB (DSF) Automatic/Manual Remote Debugging Launcher".