Jump to content

Service won't start after upgrade


MattHamilton
 Share

Recommended Posts

My client is currently running 5.1.3 (Win64) and I am attempting to upgrade to 5.2.4

 

I have attempted this every way I can think of with no success.

 

If I perform an XML based upgrade the service will not start after the upgrade.

If I perform a manual debug startup I receive the error "the procedure entry point k32getprocessmemoryinfo is not found in kernel32"

 

In researching this I found some mention of installing C++ runtime, Visual C++ 2008 runtimes are already installed.

Another response was to uninstall and re-install the software.

When I attempt to do this the installation nears the end and then fails reporting an error with the installer.

 

 

Researching this I have found posts that Windows XP is not supported, the server I am installing on is Server 2008 64.

 

Do I need to upgrade to an even newer version of Windows server to install the latest version?

Link to comment
Share on other sites

I have done further testing on this and have confirmed that the installation fails on a new test Server 2008 64 installation but is successful on server 2008 R2

There is no mention of this compatibility issue in the release notes and all I have found in the forum is a very uninformative post, possible from a dev, mentioning that the app is now compiled in VS2014 and may not work under XP which I'd be surprised if anyone would be using to run a production server, Server 2003 is the equivalent server OS version

Worse still an in place upgrade using the XML link is performed without detecting this issue and results in a non-starting service.

 

Could someone please confirm why as of 5.2 the Vodia pbx is not compatible with Server 2008 and presumably Vista and older Windows operating systems as well.

Link to comment
Share on other sites

Here's some more info I have uncovered on the Kernel32 reference which is causing the service startup failure.

 

The MSDN page for GetProcessMemoryInfo (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683219%28v=vs.85%29.aspx) suggests that this due to a difference in linkage between Windows 7 and earlier versions; Windows 7 directly defines GetProcessMemoryInfo as K32GetProcessMemoryInfo in Kernel32.dll, whereas earlier versions call GetProcessMemoryInfo in Psapi.dll which wraps to K32GetProcessMemoryInfo.

Possible solution:
"Programs that must run on earlier versions of Windows as well as Windows 7 and later versions should always call this function as GetProcessMemoryInfo. To ensure correct resolution of symbols, add Psapi.lib to the TARGETLIBS macro and compile the program with -DPSAPI_VERSION=1. To use run-time dynamic linking, load Psapi.dll."

 

 

Could the developers please consider that although they are likely to be compiling and testing on Windows 7 or newer systems any currently supported Microsoft server platform should be expected to be still used in production.

Windows Server 2008 has extended support from Microsoft until January 2020, even Windows Server 2003 R2 still has extended support to July 2015.

Link to comment
Share on other sites

Unfortunately the different Windows versions come with different libraries, which have a couple of backward compatibility issues, especially with XP (which is server 2003) and before (Windows Millenium, WIndows 95, WIndows 3.1 and so on). Our strategy is now that the 64-bit build uses pretty much the latest stuff, which is Windows 7 and higher. The 32-bit builds use a much older tool chain which should work even on XP.

 

Bottom line is to use the 32-bit version if you have compatibility issues. It would not take you as far as the 64-bit edition in terms of CDR and number of phones you can connect on TCP/TLS; but most installations that use older OS versions don't use that much resources (does not justify the OS upgrade).

Link to comment
Share on other sites

Thanks for the reply but unfortunately the 32 bit version won't install either.

I have provisioned a 32 bit Windows 2008 server and have exactly the same result with the 32 bit installation package.

I managed to find a 5.1.3 32 bit installation package which installed fine, but as with the 64 bit version the service doesn't start after upgrading.

 

Screenshots of the error and system details are attached.

 

I don't understand why you keep referencing desktop operating systems, Windows XP and Windows 7.

Who in their right mind is running a production system on non-server platforms, do you do any testing of new builds on different platforms as there seem to be a lot of assumptions being made?

Is your software no longer fit for commercial use?

post-56181-0-91698000-1420757635_thumb.png

post-56181-0-88116200-1420757637_thumb.png

post-56181-0-84505700-1420758749_thumb.png

Link to comment
Share on other sites

The installer just takes care about registering the service and copy the files. So what you could do is install the 64-bit version and then manually copy the 32-bit executable over (32 bit will also work on 64 bit OS, but not the other way around). The links are in http://vodia.com/downloads/pbx/version-5.2.4c.xml you can just copy and paste them.

Link to comment
Share on other sites

Quoting my previous post

"I managed to find a 5.1.3 32 bit installation package which installed fine, but as with the 64 bit version the service doesn't start after upgrading."

 

The installation failure aside the 32 bit upgrade failed in the same way as the 64 bit, resulting in a non starting service.

 

Let me know if you have any plans to do testing of your software prior to releasing new versions or in response to reported issues on any platforms other than recent version desktop operating systems.

As it stands this is a completely unacceptable level of support for a commercial application and I will being researching alternative solutions for my clients.

Link to comment
Share on other sites

Sorry the problem is related to the operating system. If you upgrade your OS it will work with no problems.

 

We did not do this just for fun. The point is the development platform which we have upgraded (Visual Studio). It wasn't our idea, but a upgrade of the tool chain results in backward compatibility issues. I am not sure if Microsoft broke the backward compatibility on purpose to make more money on selling OS upgrades or if there are actual technical reasons for this (new features only available on new OS versions). We could move back to the old development tool chain; however then we have eventually outdated software that is generating sub optimal code. That would put those clients at disadvantage that are using the latest OS.

 

That all said, I believe it is a reasonable to recommend to the 64-bit versions for all modern installations and use the old tool chain for the 32 bit version for an enhanced backward compatibility. Also the number of clients using the older versions of Windows is really going down. From a customer focus point of view, we need to focus on the majority of clients who are using newer OS versions.

Link to comment
Share on other sites

Yes but the 32 bit version doesn't work on Windows 2008 (32bit or 64bit) either so I'm not sure what enhanced backward compatibility you are referring to.

 

Windows Server 2008 is a currently supported platform with extended support from Microsoft until 2020, I am certainly not going to recommend that my clients upgrade their servers because you don't know how to or can't be bothered compiling and testing software to support this version.

FWIW even Visual studio 2015 offers client compatibility back to XP/Server 2003

http://www.visualstudio.com/en-us/products/visual-studio-2015-compatibility-vs.aspx

I have also provided information suggesting how to resolve the specific error encountered when starting the service on Server 2008

 

Most concerning is the lack of information and informed support.

Nowhere does your website or any specific forum responses mention which version of windows are supported or that some are not compatible, You have even asked other customers with similar issues to test for themselves which is what I have had to do and have proven your assumptions wrong.

Link to comment
Share on other sites

  • 3 weeks later...

Looks like we found the problem. Actually the problem was not a compiler problem, it was that we were using a (not really needed) Win API function that was not available in Windows Server 2008. We have fixed that issue; if you like please upgrade to 5.2.4d ( http://vodia.com/downloads/snomONE/version-5.2.4d.xml ) which is available for Win32 and Win64.

 

It might even work on Windows XP again; we were not able to try that out.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...