Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

SRPControls64.ocx compatibility with server 2012 R2

Using an RDP remote connection have the following issue.
Tried installing OI10.2.1 at a client and whenever starting the application OI aborts (Crashes).
OI10 starts OK in development mode and the IDE displays correctly. Ass son as the application is started (Ctrl L) OI aborts.
Below is the event log suggesting SRPControls64.ocx is the cause of the crash.
The IT support suggest that SRPControls64.ocx is not compatible with 2012 R@

Any suggestion would be appreciated.



  • Chris - I don't know what the problem is so maybe Kevin will have some ideas when he sees this message tomorrow. Windows Server 2012 is no longer a support platform so we do not guarantee our products will work. However, perhaps this is easy to resolve.

    Can you provide additional information such as the version of SRPControls64.ocx and what specific control was loading at the time of the crash?
  • The SRPcontrols64.ocx version is as follows:

  • Sorry wrong image:

  • Chris - My apologies. I overlooked that the version was in the error message. It would still help to know what specific control was being loaded. If there are multiple controls on the form being launched then you might have to remove them and add them back one at a time to isolate the offending control.
  • edited February 6
    Try installing the VC++ 2013 Runtime on that machine and see if that helps.
  • @DonBakke I'm not directly involved in this installation so I can't definitively answer your question but I can narrow it down to four controls.
    The four controls initially loaded are
    • Ribbonbar
    • Popup
    • Statusbar
    • Subclass
  • @AusMarkB - I'm assuming that any further reporting on this issue will be after the VC++ Runtime has been installed.

    Are you able to narrow it down because of your own experience or do you have it on good authority that these are the controls initially loaded in this instance? Regardless, it would be helpful if each of these can be tested individually. My hunch is that the culprit is the Ribbon control. It shouldn't be too hard for someone to create sample forms and temporarily make these the startup forms for the application.

    Keep in mind that our ability to troubleshoot this is limited because we do not have ready access to a Windows Server 2012. So while it is always a good idea for the customer to do everything reasonable to isolate the problem, it is doubly so in this case.
  • Not knowing how long it will take to organise installation of the VC++ Runtime, I just thought I'd offer up a little more available info while we wait. :)
    From personal experience and by looking at the app in front of me, I can see that those are the four controls on the mdi which is the first screen to be loaded.... unsuccessfully.
  • The client has decided to upgrade their server because Server 2012 R2 is no longer supported by Microsoft. Hopefully that will fix the incompatibility issue with SRPcontrols64.ocx.
  • I'm optimistic that it will. But if not, we'll be in a better position to address the problem.
  • edited February 6
    Keep the aforementioned VC++ 2013 Runtime in mind after the upgrade. It probably won't be necessary, but since organizing the install involves some effort, it wouldn't hurt to make sure it's run before your next test.
  • It's worth noting that our installer runs the VC+ 2013 redistribution installer automatically, so another option is to just run our installer.
  • VC+ 2013 redistribution installer done, came up with repair, so, was installed by the SRPControls64 install.

    Still same issue - we need to do a test install on another client site that is 2016 server to ensure nothing is wrong with our server setups.

    The current 2012 server client (with this issue) says is looking into 2012->2016 upgrade.
  • Our installer installs these runtimes for you, by the way. So, if you've used our installer, it should have everything you need. I suspect this server is simply missing some dependencies, which can happen for a host of reasons. Upgrading out of an unsupported server OS is the correct move regardless.
  • FYI:- OI9 - Srpcontrols.ocx is running OK
    Would I then assume that 64 version requires extra stuff!
  • The 64-bit version has code specific to DPI, but even though that is "extra stuff", note that in Windows, there are 32-bit and 64-bit versions of all kinds of DLLs. There are numerous ways 64-bit could fail while 32-bit does not. One way to check is to use Dependency Walker, but even then, this is not a foolproof way to isolate the issue. If the client wasn't going to upgrade the OS, I'd recommend doing an OS repair.

    One thing that has not been made clear to me is whether or not you just copied the OCXs to this machine or ran our installer. If you haven't run our installer, this is the first course of action.
  • Yes, the SRP controls installer was run - the new version with the selection option.(Thanks again for that)
  • Awesome. Then their OS installation is bad. Time to repair or upgrade.
  • For what its worth, I stumbled upon a tool that seemed a little better than Dependency Walker for tracing through the 'modern' Windows APIs as it is a 'more updated' (relative term) and open source version of that tool.


    Your mileage may vary....
    Like Kevin said, there are 'a host of reasons'. Knowing the issue is sometimes very different from solving the issue!
Sign In or Register to comment.