Windows 7 Service Pack 1 Download 32-bit
Shanta Plansinis
Thank you for this great help. I first searched google for currentworkingdirectory, path, application directory, etc. and didn't get much help. I'm including those search terms here so others can land here as well.
If you want to get the executing directory, you can still use : string currentDir = Path.GetDirectoryName(Assembly.GetExecutingAssembly().CodeBase);
I use the Phil's method to set it back to the process.
Just wanted to personally thank you for this information. I was incurring the dreaded Error: 1054 due to my application calling settings out of a conf file. Little did I realize, my application was trying to fetch this file from within the system32 folder, not the folder local to the service executable itself! At any rate, this simple one-liner addressed my startup issue, thank you kindly!
On a related note, for a ASP.net web API (at least in 4.7.2, which is where I ran into this) the default current directory when debugging is C:\Program Files\IIS Express, this solution seems to help in the web world as well as the windows service world.
We've written quite a few of those Delphi 32-bits services ourselves, and the only thing that actually helps us "debug" the services running on servers (64-bit included) without the source code is Sysinternal's (now Microsoft Technet) Process Monitor.
In your specific case, I'd download Process Monitor (it's a simple executable) and run it and then set it up to filter only your service's .exe application. Look around for it's docs, but this is actually a very simple filter.
Keep Process Monitor running (filtered) on both machines while you start the service. Compare results from Process Monitor. I bet you have something like a missing registry key, or a missing directory or permission which causes the Delphi app to raise and Exception. This should be easy to spot on Process Monitor. Even more if you have a working machine to compare to.
I had the same problem, but Ricardo Pardini's hint with Process Monitor was the solution, I found out that the service (even at the time of just installing it) was looking for a dbExpress DLL which was not in the application directory nor in the search path. Copying the DLLs into the same folder resolved the problem.
If it's just a POS (Plain Old Service ;) ) you can follow the instructions here to manually install it as a service. That way you will get around a failing install routine if the application itself works.
It's probably trying to read something from the 64 bit version of windows rather than the 32 bit version of windows. Make sure that you have the 32 bit sql server client installed and functioning properly. Other than that post the appcrash which should tell you which DLL to put in wow32.
Browsing the internet, I found the following describing on how to setup JBoss as a Windows service -
I was able to successfully install it as a service.
The weird and ANNOYING issue is that when I stop the service from within the Services administrative tool, it causes the machine to power down.
Am I missing something here? This is MOST annoying.
I have JBossAS running as a service on a Windows 2003 server and I shut it down every night for the backup and the server has never shut down.
Also post the results of this command (replace service-name with the service name in service.bat):
sc sq service-name
JBoss Native 2.0.4 is the latest version, and yes it names the service JBAS50SVC in anticipation of the JBossAS 5.0 release, but I have used 2.0.4 with both AS 4.2.2 and 5.0.0.CR1 without any problems (it should work with 4.2.3 with no problems).
One way to tell if you are running the 64-bit Windows is if you have both a Program Files and a Program Files(x86) directory. There are other ways also (and if I was at home where I am running 640bit Vista, I could tell you), most likely by looking the My Computer Properties or at System Information.
My guess would be that if you see a lot of x86 stuff, then you have a 64-bit system and the stuff you are looking at is compiled for 32-bit - the 64-bit Windows will run 32-bit software. Therefore, you can run a 32-bit JVM on 64-bit Windows, so that is not a clear indication of the OS type.
Regardless of all that, you should ensure that the JBoss Native you are using matches the OS type - that is, if the OS is 64-bit, you need the 64-bit variation of JBoss Native.
The service description looks OK, but I cringe at seeing JBossAS installed in Program Files - having spaces in a path can cause some Java libraries fits. I keep mine at d:\opt\jboss\jboss-4.2.3.GA. If you move it out of Program Files and the problem goes away, I will add this problem to my growing list of things that can go wrong when running Java apps in a path with spaces in it.
I was hoping that "sc qc" would also list the services that the jboss service depends on, but it doesn't. Could you look that up in the services manager window? It is the Dependencies tab on the Properties dialog box for the service.
Also, please provide the information I asked for in my prior post.
I do not see anything unusual in the DLLs being used by the JVM. That and your earlier statement that using shutdown to stop the app server does not halt the machine leads me to believe that the issue must be related to the service code or configuration, and not to JBossAS.
Is there nothing in the system logs that would indicate why the system shut down?
The only other thing I can think of is that there some system-wide option is set, and that is causing the shutdown when the jboss service is stopped. Something like "shut down when the last process run by user xxx is stopped". Or perhaps some other service was inadvertently set to depend on the jboss service. Or there is a scheduled task that periodically runs and checks on the system status and when the jboss service is stopped, that task shuts down the system.
I've created two applications: one is console application and one is windows service. Both application run same codes to print crystal reports to printers and run at 32 bit. I can have multiple instance of console application running without any issues. When I run the windows service version, the first time the service works fine. But after I restarted the windows server, the crystal report throw Sysstem.Runtime.InteropServices.COMException.
Both console application and windows service run at 32 bits. The user runs the service is domain controller who has admin permission. And the same problem happened on an web application hosted on IIS of the same server.
The CR .NET SDK is intended to be used as a light reporting engine. If you need a robust fault tolerrant system you should move to [Crystal Reports Server _server/] or our [BusinessObjects Enterprise ] product line. They have fail safe systems built in.
Both Close() and Displose() method have been called after report printing. Also the windows service is stopped and the process is killed. It seems that the COM object doing the printing job is still alive, so starting the service again immediatly didn't work with the same error message. If I start the service again in 15-20 minutes, the crystal report will start working again.
Cannot reproduce the problem in my computer which is 32 bits windows xp which is my dev pc. And doesn't happen to the 32 bits console application using same code in 64 bits Windows Server 2003. It only happened on windows service and IIS service on 64 bits Windows Server 2003.
Just to check if permissions are limiting visibility to the printer driver or service, would you try giving the Windows Service running the CR.NET an OS User Identity with greater permissions? This is just for a test.
Forgot to metion that the server was also a domain controller. The user I set for the windows service was domain admin. And the domain admin had full access to the only default network printer installed. Console application was run by domain admin as well. I could run multiple instance of console application without any printer error message.
I'm struggling to figure out what is going on, but it has a pretty widespread effect on a system I'm working with. I originally asked this on stack overflow and It was recommended I check here. OP StackOverflow
I have several machines running a service, but when I try to query the service (both in .net and in powershell) the service is not found. When I connect to the machine via RDP, the service shows up. I've already confirmed that I had permissions on the service, including granting explicit permissions to the service for my user using subinacl. All the servers are running Windows Server 2012 R2 Datacenter including the domain controller where all the machines are connected to.
I do get a result back from get-service -computername $server but it doesn't list the service I'm looking for. Is there a group policy or windows configuration that I'm missing here? Why would some services show up remotely but not all of them? I think this may have something to do with 32 bit vs 64 bit applications. The previous version of the service I was dealing with was 32 bit but now it is 64 and the problem is showing up. That would also explain why some but not all of the services show up.
This problem has plagued me for weeks and I finally give up. InDesign Server installs successfully and the InDesignServerService starts, but the server does not run. I can only run the server from the command line. I've followed these installation instructions but run into the following problems:
2. I cannot install or load the snap-in to MMC. When I try to install regsvr32 InDesignServerMMC.dll it cannot be found (as it's not in the InDesign Server directory). However InDesignServerMMC64.dll is in there and I was able to load the snap-in using regsvr32 InDesignServerMMC.dll, but the server still only runs when being started from the command line.
Well, when you run it using command line if you close the command line, of course that servers going to shutdown. So, if you wanna run without any extra window opened, you have to start your service. Go to the windows service window (administrative tools) and start the service (it's installed automatically).
c80f0f1006