> Maybe try running the service as the same user as the one you use when > running from the command line. That should help narrow down what is > going on.
Sorry, I should have mentioned that I had already tried that, and that it made no difference. > >> I guess check the obvious. Does the dll exist where the app is looking? > > > > It does exist yes. I have a working theory in fact that it loads the > > DLL, but it is the dependencies of that DLL (which will be various > > Windows system DLL's) that it can't load. > > Is there a tool (ProcessMonitor?) that you can use to monitor attempts > to load DLLs? What an amazing little tool. Thank you! I found it here - https://docs.microsoft.com/en-us/sysinternals/downloads/procmon I was able to configure it to just monitor prunsrv.exe, and then I just tried to start my service from the Windows Service Manager. It generated a lot of information, but once I dug through it, it was very obvious what was happening. The short of it, is that there is no problem with Procrun. The long of it... The problem was that we ship two versions of the DLL native library with the application, and each of those is wrapped inside a distinct jar file, e.g. ourlib.jar and ourlib-debug.jar. The debug version is there should we have any problems and we need to enable it to get further information. When starting our application standalone (i.e. NOT as a service), it uses Codehaus's AppAssembler Booter which tightly controls what is on the classpath from a list inside an XML file. The debug version of the Jar is NOT on that list. For running the application as a service we had set `--Classpath="C:/Program Files/FusionDB Server/lib/*"` to prunsrv when we installed the service. When we subsequently started the application via the Service, both production and debug versions of the ourlib jar, were loaded to the classpath. As those ourlib jars contain the same package and class names, we can't guess which will be chosen when we ask for one. At runtime Java was deciding to use the debug version and not the production version. The debug version of the DLL native library has an additional dependency on MSVCP140D.dll. The MSVCP140D.dll (the 'D' is for debug) is not part of the standard Microsoft Visual C++ redistributable package that is often installed, it is only available as part of Visual Studio! This also explains why we did not see this issue on our development machines! See - https://docs.microsoft.com/en-us/cpp/windows/preparing-a-test-machine-to-run-a-debug-executable?view=vs-2019 Whilst the problem was ultimately with our use of the classpath... this one was a tricky one to diagnise and so I have included the details here in-case anyone else hits a similar issue with Procrun in future. p.s. Thanks for all the help Mark :-) Cheers Adam. -- Adam Retter skype: adam.retter tweet: adamretter http://www.adamretter.org.uk --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
