.net - What causes error HRESULT: 0x80010105 (RPC_E_SERVERFAULT)?

link之家

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

I created a ASP.NET web service that uses a 3rd party payment processing engine to authorize credit card transactions.

The web service is hosted on a separate application server and connects to the payment processing server via an ActiveX object ( .ocx extension). Lately, it has been generating a HRESULT: 0x80010105 (RPC_E_SERVERFAULT) exception when I try to establish an connection to the application using an " IsAvaiable " check.

Does anyone recommend an good place to start for researching this issue?

(I know contacting the vendor would be the first option, but I want to have my "ducks in a row" before we contact technical support)

I've had the same error ( RPC_E_SERVERFAULT ) using ActiveX objects in web services. Whenever the ActiveX object crashed, IIS would throw this error, which would mask the reason that the object crashed (for us it was usually crashing while loading an invalid file that it needed to process and return values from).

Have you checked the system logs etc. to see if your ActiveX control has logged the actual error anywhere?

If you can't see anything obvious then I'd recommend contacting their technical support to figure out the best way to diagnose what the actual error is and if it's logging its errors anywhere.

I checked the event log of the web service server and did not see any errors related to the RPC_E_SERVERFAULT error. I do not have access to the application server, maybe I might find something there. – Michael Kniskern Jun 10, 2009 at 1:17

I know this is stack overflow and there should be a programming answer here, but you mention no updates or software changes to the failing machine. If there were no software changes it is most likely a hardware issue. RAM Fails, CPUs fail, hardware fails. If you can take the system offline and test the hardware you will probably find that a disk or a memory module is failing (NIC maybe too). It is likely the first step the vendor would have you do but if you do it yourself you can do it on your terms and might safe yourself the service charge for a few hours of their time.

@Elmue Have anything constructive to add? Verifying hardware is often a good step and I have witnessed bad ram cause a variety of errors including cryptographic signature verification issues. If crypto is failing RPC can fail because of it. The question also asked about advice when contacting a vendor, routine hardware will get one past a number of sleazy techniques phone phone agents use to dump the call. – Sqeaky Jun 2, 2017 at 4:06 I have seen several RPC_E_SERVERFAULT errors. Never was hardware the cause. This errors simply means that a COM server has crashed. The cause are mostly programming errors like buffer overflows or reading null pointers or bad error handing. If you would have problems with RAM you would see crashes in different application (not just in one server) even until bluescreens. It is impossible that a hadware problem causes crashes only in one application. – Elmue Jun 3, 2017 at 2:15 That was productive, have an upvote even though I disagree. I have seen memory corruption cause a single application to fail, even in the same way each time time. It is unlikely, but entirely possible depending on memory use and the allocation scheme of the software software. Also it prevents phone agents from telling you to check your hardware then hanging up on you. – Sqeaky Jun 3, 2017 at 3:20 It does not actually produce a .DMP file when the exception occurs. Are there other type of file extension I should look for that would be considered a memory dump. – Michael Kniskern Jun 17, 2009 at 22:45

Thanks for contributing an answer to Stack Overflow!

Please be sure to answer the question . Provide details and share your research!

But avoid …

Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers .