We do have third party tools as well as reference a c++ managed assembly. These may or may not be built for any CPU. In fact i know that the c++ managed assembly is only built for x86. However, the odd things is that if I specifically specify x64 the process will start up and work in x64. If the framework were to attempt to load the c++ managed assembly it would fail. I don't mind this, because in the code, we do not load the 32bit managed ++ assembly if we're running in 64 bit mode. Could it be that the build figures that since there is a 32 bit assembly in here it should mark the launching process (in this case a windows service assembly) as x86?
In case anybody runs across the same thing I did: I had created two new config settings (copied from the Debug config). For some reason "Prefer32Bit" flag was set to true, even though the checkbox was greyed out and unchecked in the project config page.
Though I didn't find such utility in .Net v4 folder, the setting applies to Net4 AnyCPU assemblies as well. This flag is saved in DWORD registry value Enable64Bit under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework
I often use a starter application, where I explicitly compile the .exe as x64 or x86 and ship x86 and x86 versions of the .msi. This is probably the easiest route - The performance gain is generally worth the overhead of managing additional files.
I have a windows service. In the Properties I have the platform target set as X64. In my csproj file I have changed all instances of prefer32bit to false. I am installing the service with installutil.exe when I install and run my service it runs as 32 bit. I am currently building in debug mode. What am I missing here?
Edit: I found out how to uninstall an existing service in my installer here:
stackoverflow.com How to install a windows service programmatically in C#? c#, .net, windows-services, setup-project asked by Konstantinos on 08:38AM - 11 Dec 08
Problems may occur when trying to set up Crowd to run as a Windows service with JDK 1.6. The problem is caused by a failure to locate MSVCR71.DLL, which can be found in your %JAVA_HOME%/bin. There are two options to resolve this problem:
If you are running 64-bit Windows, please note that Apache Tomcat cannot run as a Windows service if you are using a 64-bit JDK. Please ensure that you are using a 32-bit JDK. This is the recommended solution.
Alternatively, you can install a 64-bit JDK and set JAVA_HOME to its location. Then follow the same steps above for Installing Crowd as a Windows Service. You'll need to replace CROWD_INSTALL\apache-tomcat-5.5.20\bin\tomcat.exe with one compiled for 64-bit from these locations:
I don't know why the site is now throwing cert errors, try It is a popular way to convert exe's into windows services. You can download it from their site or search google and find an alternate location.
Running metabase using java is great, but what if you want to run it all the time. On windows you have the options of adding it to start up, but even then you will have to login to the machine to start metabase. So to convert it to something like a service, the best option is to run it as a windows service.
"Windows could not start the Metbase-Service service on Local Computer.
The service did not return an error. This could be an internal Windows error or an internal service error.
If the problem persists, contact your system administrator."
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.
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.
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).
The issue is with the federated arcgis server, second machine. We have noticed that on panning, zooming webmaps in a desktop browser, is causing the arcgis server to slow down and eventually services don't respond. the windows service for arcgis server is terminated, while we see the arcsoc processes are still around, almost all of them,
Could you comment on whether or not RAM and CPU resources are meant to scale based on demand? Or are they static? If static, do they meet the minimum requirements as listed here: -requirements/latest/windows/arcgis-server-system-requirement...
So if my guess is right there are a few possible solutions, I have seen the arcgisserver.exe crash when the server has a lot of services 500 and the server has low clock speed around 2.4 GHz, in this case the solutions was the reduce all the pooling minimum instances to 0 -You can up the pooling for critical services- and that stabilized the system.
The Second case that I had was a ArcGIS Server that had over 1000 services it generated the low memory error that you mentioned even though it had more than enough swap memory, the solution is shared instances , but this only works for services published out of pro so you will have to convert any ArcMap Services.
If the Windows OS is reporting virtual memory exhaustion, that's usually a pretty reasonable diagnosis and is hopefully trivial to remedy. An important thing to keep in mind is that in the latest Windows Server operating systems (2016 and 2019), the page file growth is limited to the size of the volume it is on divided by eight. This means that for a 60GB C: volume, the default system-managed settings would restrict growth of the page file to 7.5GB.