IPReq.exe crash on MSVCR80.dll

I am recently seeing a lot of crashed for my IP Servers in relation to MSVCR80.dll - I already re-installed everything related to the DLL, did sfc /scannow and such - but the crashes keep happeing, anyone have any solution?

FaultingApplicationName: IPReq.exe
FaultingApplicationVersion: 2.0.0.85
FaultingApplicationTimestamp: 5051f0eb
FaultingModuleName: MSVCR80.dll
FaultingModuleVersion: 8.0.50727.9680
FaultingModuleTimestamp: 6090c909
ExceptionCode: c0000005
FaultOffset: 00015068
FaultingApplicationStarttime: 01dc9e259548a6cd
FaultingModulePath: C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.9680_none_d090cb7c44278b28\MSVCR80.dll

What version of the IP Server/Driver?

What version of windows?

Is it internet facing?

I ended up setting the service to restart after 1 min when it crashed.

Clarion 8 based version, i think 8.0.50727.9680
Windows version is Windows Server 2019 I think

Yes it is - could that be the cause? Someone scanning or sending something which crashes it?
Sadly restarting it still causes the client to disconnect - resulting in errors as it doesn’t really reconnect itself

When I had mine online, they were less stable, so often wondered if its those random packets that appear at the firewall which is causing a problem.

May be you could log the packets going to the port(s) and see if a packet or series of packets cause the service to crash, so you’ll also need to log the service events in the windows event viewer.

Then when its crashed, look back through the event log, get a time and then look at the logged packets to see what appeared at the same time, and then look for other packets before that crash event in case its more than one thats caused the problem.

Potentially you only have to go back as far as the firewall session timeout window, which can be anything from 1 minute to several hours, its a firewall setting. Windows typically has a two hour timeout, azure only 4-5mins if you are hosting on the cloud.

I cant remember off the top of my head if the IP driver service has a timeout setting or not, but you want it to at least be the same timeout period as your firewall session timeout.

There is a chance that if the IP driver service has a longer timeout period than the firewall, that a carefully crafted packet could be sent after the first firewall timeout period which still affects the IP driver service.

IIRC it was written in Java, so have a look for any bugs that affected the Java runtime thats installed.

Edit.
To elaborate more on the packet logging. The problem with https/443 data is its encrypted and only the IP driver server decrypts the packet. So behind your firewall you could rig up a reverse proxy with TLS inspection.

Courtesy of ChatGPT:

Is there a reverse proxy which can decrypt the packets, log them and the encrypt them again before forwarding to a backend server on port 443 ?

Yes :white_check_mark: — what you’re describing is a standard architecture called:

:backhand_index_pointing_right: TLS termination + inspection + TLS re-encryption
(or HTTPS → decrypt → inspect/log → HTTPS → backend)

Many reverse proxies and load balancers can do exactly this.


:white_check_mark: What you want (architecture)

Client → HTTPS :443 → Proxy (decrypt + log) → HTTPS :443 → Backend

The proxy:

  1. Accepts HTTPS
  2. Decrypts traffic
  3. Logs or inspects it
  4. Creates a new TLS connection to backend
  5. Re-encrypts and forwards

This keeps encryption on both hops while allowing inspection.


:white_check_mark: Reverse proxies that support this

:star: NGINX — yes (very common)

NGINX can:

  • Terminate TLS from client
  • Log decrypted HTTP
  • Connect to backend using HTTPS
  • Verify backend certificates
  • Do mutual TLS if needed

You just change:

proxy_pass https://backend:443;

instead of http://.

This creates:

  • client → proxy TLS session
  • proxy → backend TLS session (separate connection)

This is normal reverse-proxy behavior.


:star: HAProxy — designed for this

Very common in enterprise environments:

  • TLS termination
  • TLS inspection/logging
  • TLS re-encryption to backend
  • Layer 7 filtering
  • Performance optimized

Often used for banking / high-security networks.


:star: Apache HTTP Server — also supports it

Using:

  • mod_ssl
  • mod_proxy
  • mod_proxy_http

Less common than NGINX/HAProxy but works.


:star: Specialized TLS inspection proxies

TLSPROXY

Designed specifically for TLS handling:

  • Terminates HTTPS
  • Forwards to HTTPS backend
  • Can inspect traffic
  • Automatic certificates supported

:star: Enterprise / commercial systems

(used in corporate networks)

  • F5 BIG-IP
  • Citrix ADC
  • Akamai edge proxy
  • Cloudflare proxy

These do TLS inspection + re-encryption by default.


:locked_with_key: What happens internally

Important concept:

:backhand_index_pointing_right: The proxy does not forward the original encrypted packets.

Instead it:

  1. Decrypts client request
  2. Processes/logs HTTP
  3. Creates a new HTTPS request
  4. Sends that to backend

Two independent TLS sessions exist.


:brain: Why people use this design

  • Keep end-to-end encryption
  • Log/inspect traffic
  • Add security filters/WAF
  • Authenticate users
  • Protect internal networks
  • Meet compliance requirements

This is common in enterprise security gateways.


:warning: Important security reality

If the proxy decrypts traffic:

  • The proxy sees everything
  • It becomes a trusted security boundary
  • Private keys and logs must be secured

The proxy is effectively a man-in-the-middle by design.

End of ChatGPT

And thats what you want on port 443, and if using port 80, a logger on port 80. This way you’ll get the raw packets to see whats going on and if a packet is causing the IP Driver server to crash or not.

Its the start of a process. If nothing shows up with the packet logging, potentially a bit of reverse engineering with something like Ghidra to see if there are any bugs in the IP Driver service.

Check that the \ClarionDataServer folder is excluded in your antivirus programme.

Other than that no idea. perhaps support at sv may be able to help.

I used pktmon to create a constant trace in etl format (convertable to pcap) - but i only see traffic from one iP (related to the user connection) - I don’t see other traffic and anything which seems to be a possible cause