I used libfcgi for Windows to create a FastCGI server app to host the PowerBuilder programming language. It works great when calling from a browser.
When called from a desktop application using WinHTTP, the server exe will terminate after 10-20 requests and a new instance starts. No error message is returned to the desktop app and nothing is written to the Event Viewer. The App Pool (w3wp.exe) does not end, just my exe. My exe is not breaking out of the main loop, it seems to be terminated.
I compiled libfcgi as a DLL without any changes using VS 2022. My C++ server exe calls the FCGI functions in the DLL.
Related
A legacy Service that I work is freezing due to database issues. And I'm looking for a simpler solution than fixing it.
In Aplication Form Version (Delphi), Windows recognize and show message that application is not responding.
Can Windows recognize when a service is not responding and restart the service?
In Service Properties the Recovery is only for failures.
In Aplication Form Version (Delphi), Windows recognize and show message that application is not responding.
Only if the main UI thread is blocked, but you shouldn't ever do anything in the main UI thread that can block it. Bad code design.
Can Windows recognize when a service is not responding and restart the service?
Not automatically, no. You need to fix your database code so it doesn't freeze up anymore in the first place. If that is not an option (which I highly doubt) then you will have to write a separate watchdog thread/process to monitor your code/service and kill it if it freezes up. If you kill the entire service, then Windows failure actions can be used to restart it.
We have a windows service (written in C#) that uses a 3rd party DLL to communicate with a COM printer.
Already tested the windows service in 4 local machines, and in every case the printer works correctly.
We also have this windows service already deployed in production in several clients and it also works correctly, but now we where deploying it to a new client and in every test we make the DLL is unable to open the COM port (already checked to see if it's in use by another application and nothing).
But the strangest thing is that if we launch the service .exe from command line it works correctly, so we tried launching the service as the user connected to the machine (instead of Local System) and even so it doesn't work.
What can be causing this? Is there any way, either by Windows configuration or by some software, to prevent Windows Service to communicate with the COM port? Or is there any other explanation?
Sorry to all of you that came here looking for a solution to your problem, but my solution was to change the 3rd party DLL.
I have a Linux system with:
a daemon that communicate with another device via RS232 port.
a php + javascript web site that talks to the daemon through a
socket.
Now the boss wants to find out how much of an effort is required to port all these onto Windowze.
Having never really programmed on Windows before, I'd like to ask how easy/hard this is going to be and what the options are.
Thanks,
PHP will probably run as is. Javascript runs in the web browser, and will run as is. Your daemon is a service on windows. Apparently it listens on a socket for commands from the web page via javascript.
You did not state what language you are targeting for the service. Some languages such as C# dot Net, have built-in libraries for making clean services that can pause, stop, start, and interact with the Windows Service Control system. C# would be a good choice to make a service that can install and remove itself easily, and it supports nice high level socket control to listen to the PHP and javascript code. I have used perl, C#, C++, and even Visual Basic running as a service, so the choice is yours.
If your choice of Windows language is that compiles to some .EXE, then a low-level way to add a service is as follows. You will need INSTSRV.exe and SRVANY.EXE, which come on the Windows Resource Kit, or can be downloaded easily with a quick web search.
The short version :
After you get the server runnign when you are logged in and debugged, install the APP server as normal to the C:\Program Files\APP directory. This would be the app that connects to the serial port and does what you want via sockets.
Copy instsrv.exe to your C:\WINDOWS\system32 directory/
Copy SRVANY.EXE to C:\Program Files\YOURAPP
From command prompt, run this command – INSTSRV YOURAPP "C:\Program Files\YOURAPP\srvany.exe"
Run the Registry Editor (REGEDT.EXE)
Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YOURAPP: create a ‘Parameters‘ key (folder)
Under the this key, create a REG_SZ string value called Application and add in this data C:\Program Files\YOURAPP\YOURAPP.exe
Close Regedit, then open the services console in administrative tools, or start, run, services.msc, confirm it is set to start automatically and the logon account is LocalSystem. Then unclick the Allow Service to Interact with Desktop. If you click this, it will interrupt you on Windows 7 boxes whenever it writes to the screen.
Start the service, check in Task Manager, you will see YOURAPP.exe inthere, and if you stop the service then YOURAPP.exe will disappear.
The long version
Details on this are at http://support.microsoft.com/kb/137890
I have created the necessary manifests for my COM server DLL and a client application to work registration-free in Windows XP. I've tested all kinds of combinations (with and without a registration) and in all cases the client application sees the side-by-side version of the library if the manifests are present, and the registered one if not (or a COM error if there is no registration at all). I've tested on my Windows XP development machine, and given the files (DLL, client EXE and one manifest for each) to co-workers, who've also run everything successfully on their own Windows XP machines. The manifests are external XML files, not embedded resources. So far, so good.
However, when I copy the files to a Windows Server 2003 machine, it doesn't work. I get a silent failure, but an application error in the Application Event Log (see below). If I unregister the DLL and remove the manifests, I get a similar error (silent at the command prompt, but an application error in the event log). Obviously there is some problem finding the registration. I have reproduced this on every Windows Server 2003 machine I can access at our company. According to the Microsoft documentation on side-by-side/registration-free COM, it's supposed to work on Windows XP and later, and Windows Server 2003 and later.
To be clear, the same client runs perfectly on those same Windows Server 2003 machines against a registered (i.e., using regsvr32) version of the same COM DLL, under the same login credentials I'm trying to use for registration-free COM. In other words, there are no intrinsic issues masquerading as registration-free COM problems - this client and server operate fine when the server is registered globally in the registry.
Anybody have any ideas of how to investigate further? I'm not an expert on Windows Server, but is there perhaps some policy setting that would need to be changed to enable this support? If I can locate the necessary change, our tech support/infrastructure people will probably have no probably doing it, but I can't rely on them to research the issue too as they are swamped.
In case it matters (I don't think it should, but you never know) the DLL is written in Delphi 2007, while the client is written in Visual C++.
Event Type: Information
Event Source: Application Error
Event Category: (100)
Event ID: 1004
Date: 5/2/2009
Time: 8:07:45 AM
User: N/A
Computer: ***server name****
Description:
Reporting queued error: faulting application ***program name***.exe, version 0.0.0.0, faulting module ***program name***.exe, version 0.0.0.0, fault address 0x0002ac9e.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
One thing to look for is that whether the exe has an internal manifest. In XP, the exe manifest search order is external then internal. In Server 2003 and later, the order is internal then external.
With a COM server created in Delphi 7, I have seen similar problems if the COM server was unregistered and the client application started under a restricted user account, because Delphi's COM implementation always tried to update the registration information, even when the DLL's RegisterServer function was not explicitly called.
To see whether this is a problem, attempt to run the client application on an account with unrestricted administrative privileges.
MSDN mentions, that under Windows 2003, problems with registration free COM servers should be detailed in a specific section of the system event log:
When troubleshooting registration-free
COM issues, the Event Viewer on
Windows Server 2003 is your friend.
When Windows XP or Windows Server 2003
detects a configuration error it will
typically show an error message box
titled for the application you have
launched and containing the message
"This application has failed to start
because the application configuration
is incorrect. Reinstalling the
application may fix this problem." I
advise that whenever you see this
message you reproduce the problem on
Windows Server 2003, consult the
System Event Log and look for events
from the SideBySide source. The reason
I don't suggest that you look at the
Windows XP Event Log in these cases is
that it will invariably contain a
message such as "Generate Activation
Context failed for [path][application
filename].Manifest. Reference error
message: The operation completed
successfully," which doesn't help
identify the problem.
http://msdn.microsoft.com/en-us/library/ms973913.aspx#rfacomwalk_topic6
Also, if possible, tell us the file names and contents of the manifest files you use.
I am trying to auto update my current application to new application in windows desktop using win32 api . And my application is running in background. so is there any api Microsoft providing for auto updating application or is there any procedure .please help me so that i can make update my appilication in windows desktop in vs 2005 using win32 .
Thanks
KamalBhr
AFAIK there is not Win32 API nor should there be. You will have actually have to write it. :|.
If you expect frequent updates to the application, e.g., in an environment where you want to push updates without user interaction.
on application start, spawn a copy of the the executable.
either periodically or through user action, check if there are updates available.
kill the process, replace the necessary files. restart the application.
as you spawned a copy of the executable you are free to overwrite it whilst the application is running.
Alternative, download the update packet to a directory. On next application start check if there are updates to be applied.
HTH,