2


I am trying to build a JNI-Wrapper for UIAComWrapper.dll to be able to automate Windows-Code using Java-Calls. Unfortunately, if I only try to include my C#-Dlls, which includes Wrapped Automation-Calls (directly linked to UIAComWrapper.dll), it prints out the following error:

onecoreuap\inetcore\urlmon\zones\zoneidentifier.cxx(359)\urlmon.dll!00007FFFAC5005D0: (caller: 00007FFFAC50010D) ReturnHr(1) tid(1b18) 80070002 Das System kann die angegebene Datei nicht finden.

Why I assume that this error causes my problem with JNI? Because the exception information prints me out the following (excerpt only):

siginfo: ExceptionCode=0xe0434352, ExceptionInformation=0xffffffff80070002 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x00007fffa4870000

It's the same stack address as stated in the first error message box (80070002).

I created the following Header-File to access my DLL:

#pragma once
#using <mscorlib.dll>
#include <iostream>
#using <SharpAutomation.dll>

using namespace std;

class BridgeCredentialFactory
{
public:

    // Provide .NET interop and garbage collecting to the pointer.
    static CredentialHandler::HandlerTypes::GenericCredentialHandler^ getCredentialHandlerFor(CredentialHandler::Maps::Browser browser) {
        CredentialHandler::HandlerTypes::GenericCredentialHandler^ handler = CredentialHandler::CredentialFactory::getCredentialHandlerFor(browser);
        return handler;
    }
};

class BridgeGenericCredentialHandler {
public:

    CredentialHandler::Maps::Browser b;

    BridgeGenericCredentialHandler(CredentialHandler::Maps::Browser browser) {
        b = browser;
    }

    void enterUsername(System::String^ username) {
        CredentialHandler::HandlerTypes::GenericCredentialHandler^ handler = resolveInterface(b);

        handler->enterUsername(username);
    }

    void enterPassword(System::String^ username) {
        System::String^ mystring = username;
        CredentialHandler::HandlerTypes::GenericCredentialHandler^ handler = resolveInterface(b);

        handler->enterPassword(mystring);
    }

    void enterCredentials(System::String^ username, System::String^ password) {
        CredentialHandler::HandlerTypes::GenericCredentialHandler^ handler = resolveInterface(b);

        handler->enterCredentials(username, password);
    }

    void clickLogin() {
        CredentialHandler::HandlerTypes::GenericCredentialHandler^ handler = resolveInterface(b);
        handler->clickLogin();
    }

    void clickCancel() {
        CredentialHandler::HandlerTypes::GenericCredentialHandler^ handler = resolveInterface(b);
        handler->clickCancel();
    }

    bool windowExists() {
        CredentialHandler::HandlerTypes::GenericCredentialHandler^ handler = resolveInterface(b);
        System::Console::WriteLine(getBrowserType());
        return handler->windowExists();
    }

    CredentialHandler::Maps::Browser getBrowserType() {
        CredentialHandler::HandlerTypes::GenericCredentialHandler^ handler = resolveInterface(b);
        return handler->getBrowserType();
    }

private:
    CredentialHandler::HandlerTypes::GenericCredentialHandler^ resolveInterface(CredentialHandler::Maps::Browser browser) {
        switch (browser)
        {
        case CredentialHandler::Maps::Browser::Chrome:
            return gcnew CredentialHandler::HandlerTypes::ChromeCredentialHandler();
            break;

        case CredentialHandler::Maps::Browser::Firefox:
            return gcnew CredentialHandler::HandlerTypes::FirefoxCredentialHandler();
            break;

        case CredentialHandler::Maps::Browser::Edge:
        case CredentialHandler::Maps::Browser::InternetExplorer:
            return gcnew CredentialHandler::HandlerTypes::InternetExplorerCredentialHandler();
            break;

        default:
            return gcnew CredentialHandler::HandlerTypes::ChromeCredentialHandler(); //ToDo noch nicht wie gewünscht
            break;
        }
    }
};

I checked the type of my assemblies, everything is set to x64. The only thing I could imagine to be the source of error is an inexpertly integration of the DLL-file. If my assumption is right, I would be very grateful to get teached by any of you.

I googled for days, so I would be surprised, if you could only send me a helpful link (if you found something anyway, I'd be very happy to benefit; I love surprises).

Could anyone please help me resolving this issue? In case you need anything else to be able to contribute, please let me know :)

Some more code as requested:

The call starts with:

CredentialHandler::HandlerTypes::GenericCredentialHandler^ handler = BridgeCredentialFactory::getCredentialHandlerFor(CredentialHandler::Maps::Browser::Chrome);
    handler->enterUsername("Test");

Here we call the method enterUsername, which is used in the particular handler. This executes a C#-Method enterUsername():

 public void enterUsername(String username)
        {
            if (windowExists())
            {
                Mouse.MoveTo(CredentialsHandler.Utils.GetCenterPointFrom(EnterCredentials.InpUsername));
                Mouse.Click(MouseButton.Left);
                Keyboard.Type(username);
            }
        }

Code isn't clean yet and will be enhanced after solving this issue, promise ;)

Kitzng
  • 21
  • 2
  • Something I haven't mentioned yet: This error does not cause any trouble in my C++-Code. It works fine and I am very happy with it's functionality. JNI, on the other hand, is quite sensitive to such messages, so I assume that there are only two options: either resolve this issue or ignore errors on such a level. – Kitzng Apr 02 '19 at 14:58
  • The error message says it can't find the file. I've seen this error message with dlls that were compiled for Win95. How old is the SharpAutomation.dll? What is the timestamp? It may not be compatible with Net Library 3.5 or later. One solution is to write a c++ wrapper so c# can access the dll. – jdweng Apr 02 '19 at 15:05
  • Just built this one: SharpAutomation.dll SharpAutomation.dll d:\users\kitzng\source\repos\TestForJni\x64\Debug\SharpAutomation.dll No N/A Symbols loaded. D:\Users\kitzng\source\repos\TestForJni\x64\Debug\SharpAutomation.pdb 4 1.00.0.0 02.04.2019 16:19 000001C823700000-000001C823706000 [20088] TestForJni.exe [1] TestForJni.exe – Kitzng Apr 02 '19 at 15:10
  • @jdweng but I just noticed that this dll appears twice in my modules debug window. The other one claims "Native debugger skipped loading symbols for managed module." – Kitzng Apr 02 '19 at 15:12
  • Can you step through code to get more info on exception? Errors starting with 0x8 (80070002) are null pointers (or addresses outside assigned memory errors). Managed c# calls are protected against access memory outside the memory blocks assigned by the compiler. I think the error is due to "handler". See last answer at following posting : https://stackoverflow.com/questions/27062461/trouble-with-passing-handle-to-managed-object-using-pinvoke – jdweng Apr 02 '19 at 15:25
  • I am not using PInvoke here, it's a C++/Cli Program, which calls DLL-methods directly. – Kitzng Apr 02 '19 at 15:41
  • But if the c++ is returning Un-Managed memory you must copy data in c# to managed memory before using. – jdweng Apr 02 '19 at 15:44
  • But it works as a Console Application..? Wouldn't it crash instantly and not be working at all? – Kitzng Apr 02 '19 at 15:48
  • As a c++ application? The problem is if you are trying to return un-managed memory to c# and then try to access the data in c#. – jdweng Apr 02 '19 at 16:01
  • Ah okay, I got your point. To deal with that, I am creating C#.NET-instances before transferring those to the DLL methods. I suppose that these are managed, right? Especially, the error occurs without calling any method. I appears after launching the Console Application right away. – Kitzng Apr 02 '19 at 16:07
  • You need to use the marshal methods. Looks at examples at www.pinvoke.net. – jdweng Apr 02 '19 at 16:15

0 Answers0