Hi Konstantin
Thanks a lot for your input. You were right about the second parameter and
the call to ColInitalize, so now i'm a bit further but still get an error.
I will have a closer look on that error and hope i find a solution for it.
Cheers
snmed
Am Mittwoch, 22. Februar 2017 11:58:35 UTC+1 schrieb Konstantin Khomoutov:
>
> On Tue, 21 Feb 2017 22:55:18 -0800 (PST)
> snmed <sandro....@gmail.com <javascript:>> wrote:
>
> > Has anyone a hint, what i'm doing wrong with the Call arguments? I
> > think the last parameter is the problematic one, but i can't figure
> > out how to pass that argument.
>
> A couple of ideas:
>
> * [1] Features a comment by someone stating:
>
> | The second parameter is not present in the latest API.
> |
> | The second parameter
> | _In_ DWORD coInit,
> | is not present in the latest AMSI.dll. Use the below code if you are
> | importing to C#. [DllImport("Amsi.dll", EntryPoint = "AmsiInitialize",
> | CallingConvention = CallingConvention.StdCall)] public static extern
> | int AmsiInitialize([MarshalAs(UnmanagedType.LPWStr)]string appName,
> | out IntPtr amsiContext);
> |
> | Eler
> | 12/6/2016
>
> Which might mean you just need to drop the second 0 (coInit) and
> make your pointer to context the second one.
>
> * An example presented at [2] clearly shows the code calls
> CoInitialize() before attempting to initialize the AMSI library. This
> hints at that this library uses or is based on COM technology. AFAIK,
> to use anything COM-related in a thread, you first need to prepare that
> thread for this -- by calling CoInitialize() or CoInitializeEx(). The
> fact the second argument to AmsiInitialize() is called "coInit" hints
> at that this might indeed be the cause.
>
> Please note that since goroutines by default are multiplexed on any
> number of OS threads, you will most probably need to call
> runtime.LockOSThread() before doing anything with AMSI and make sure
> all further calls to that lib are managed by that single goroutine --
> say, by making it serve calls on a channel.
>
> * I'm not sure how MustFindProc("AmsiInitialize") is defined to behave
> with regard to "wide" vs "char" version of the API, so maybe -- for some
> weird reason -- it manages to locate AmsiInitializeA(), and that one
> gets confused with the wide character data you pass to it as its first
> parameter? Try explicitly requesting AmsiInitializeW() instead and see
> whether that fixes the problem.
>
> I'd say it's always a good idea to always refer to the API facet you
> need explicitly (and these days you usually want FooW() in most cases).
>
> 1. https://msdn.microsoft.com/en-us/library/windows/desktop/dn889862
> (v=vs.85).aspx
> <https://msdn.microsoft.com/en-us/library/windows/desktop/dn889862(v=vs.85).aspx>
>
> 2.
> https://social.msdn.microsoft.com/Forums/vstudio/zh-CN/28e6c37f-ac29-43e6-ba65-a7cbd23b6831/how-to-use-amsiinitialize-function-how-to-use-the-amsiantimalware-scan-interface?forum=visualcpluszhchs
>
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
