RSearchLib::IRSearchResponse get_Instruments(&l_instruments) throws

I have very strange behavior that I cannot explain.

Every morning I run the program (C++ COM API) that does:

1. Initialize Eikon - Starts desktop application

2. Wait for a response.

3. Create RSearch request and send request

4. Wait for the response.

5. Get response with

l_hr = m_pIRSearchResponse->get_Status(&l_RSearchQueryStatus); where l_RSearchQueryStatus == S_OK.

6. l_hr = m_pIRSearchResponse->get_Instruments(&l_instruments); - this line throws access violation that I cannot catch anyhow.

The problem is it happens every morning once or twice in a row. After I step in debug mode, the error is gone until next morning.

I know it looks weird, but I don't have a way to deal with this crash.I checked m_pIRSearchResponse is not NULL and based on msxml3.dll in the error, it's something internal.

Please check the screenshot:

image

Any idea why it can happen?

Thanks.

Welcome!

It looks like you're new here. Sign in or register to get started.

Best Answer

  • Alex Putkov.1
    Alex Putkov.1 ✭✭✭✭✭
    Answer ✓

    Your guess is as good as mine. The exception is in a Microsoft DLL. Maybe you should try updating MS XML Parser. Or maybe it's the latest version of the parser that causes the problem.

Answers

  • igorg
    igorg Advocate

    I checked the versions. I have 3 and 6 with the latest updates.

    I don't use msxml in my project. But Eikon COM uses msxml internally, so I have no chance to track the error and find out what call causes it...

    Is there a way to tell Eikon to use msxml6?

  • Alex Putkov.1
    Alex Putkov.1 ✭✭✭✭✭

    Sorry, I wish I had a quick and easy solution for this. But there isn't any. Yes, RSearch library uses MS XML Parser. Even if you had the source code for RSearch library, I don't see how it would help you since the exception is in Microsoft library for which you can't have the source code. Looking at the call stack may or may not provide some clues. But there's no straight way to get to the root cause.

  • Alex Putkov.1
    Alex Putkov.1 ✭✭✭✭✭

    The only way to tell any existing application to use MSXML6 is by changing all the version independent ProgIDs in the registry to point to MSXML6 CLSIDs. Unless your application only ever needs to run on one machine, it would be pointless to even try it. Even if you can make it work on one machine, you probably can't control what's on other machines that need to run your application. Besides Microsoft made a huge mess of XML Parser releases and their versioning. The task of forcing an existing application to use a specific version of the XML Parser would certainly not be for a faint of heart.

  • igorg
    igorg Advocate

    If I had the source code I would track the function call of ms xml parser that leads to the exception and report it to the MS.

    Based on the error, it's very possible just a NULL de-referencing. It's also possible that some function calls are illegal if xml parser is not initialized yet.

    Anyway, there is a few options on your side and almost none on my..

  • Alex Putkov.1
    Alex Putkov.1 ✭✭✭✭✭

    The option on your side is to poke around and see if you can make the problem go away, since it only appears to happen under rather specific circumstances. What could be the difference between running your application in the morning and running it later in the day? I appreciate this is easier said than done. There's no recipe and the outcome is not guaranteed. But like I said any other option is not quick and simple either.

  • Alex Putkov.1
    Alex Putkov.1 ✭✭✭✭✭

    If you consistently reproduce the issue on more than one machine and you're happy to share your source code stripped to the bare minimum required to reproduce the issue, we can open a support case for you. This is indeed an option, and the first step would be for me to reproduce the problem on my end. When you're ready with the example, feel free to reach out to me offline. We'll figure out how to transfer the files and what I need to do to compile and run it.

  • igorg
    igorg Advocate

    Believe me, I tried to to bypass the issue, but no luck for now.

    About specific circumstances: It's not about the morning. I would say it's a first time in a day which is usually a morning. So I'm suspecting that eikon updates something daily on first start of the day.. or maybe it's related to updated feeds... Again, this is just a guess.

    I will try to change your sample code and see if I can catch the same behavior.

    Thank you for your help.

  • igorg
    igorg Advocate

    @Alex Putkov.1

    I believe I found what causes the crash.
    First of all, it's not just first request per day. It's a first request per day per exchange.

    The problem is: eikon's callback function signature looks like :

    OnRSearchQueryUpdate(RSearchLib::IRSearchResponse * pIRSearchResponse) 

    What I do (and what fails) is I pass this pointer to another thread which parses the data.

    The call on this pointer crashes if there were no request for this data today. This makes me think Eikon saves the data request/response in its cache and returns a response from its cache without a problem. But if there is no cache yet... it does something not allowed in Single Threaded Apartment environment that leads to crash.

    I know how to deal with it in my code, but will test it only in a few hours.

    Anyway, it would be nice to get some exception instead of Access Violation.

Welcome!

It looks like you're new here. Sign in or register to get started.

Welcome!

It looks like you're new here. Sign in or register to get started.