Problem logging in any 1IM application



Today we were working as usual in 1IM and we got a problem compiling the database related with a script that we haven't touched for days. After this, now we can not log in in any 1IM application (the connectivity with the database is working and if we put a wrong password we got the typical login error) and we get the following error:


[810099] Assembly could not be loaded from buffer passed down.

Could not load file or assembly '1517568 bytes loaded from VI.DB, Version=7.1.2016.901, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxx' or one of its dependencies. An attempt was made to load a program with an incorrect format.
Bad IL format.


Any recommendation will be appreciated. Thanks,


  • Hi Adrian,

    You could try closing all applications/services and deleting the cache and restart.

    No idea if it will help or resolve the issue but it's worth a try.

    HTH, Barry.
  • In reply to Barry Jackson:

    Hello Barry,

    we tried to delete the local cache (I hope you mean the one in \AppData\Local\Dell\One Identity Manager\Cache) and it is still not working.

    Since looking at the crash report, the error we got it is because of:

    "Reading BLOB from table DialogScriptAssembly, column Assembly and WHERE clause: name = N'TypedWrappers_0SML2dbvZcnh2tsY1V1lZQ1ysM'"

    I want to ask if it is ok to delete this entry in the DialogScriptAssembly table or set the 'IsValid' field to 0 to find a workaround.

  • In reply to adrian.perez3:

    Did you try to do a complete compile using the Database Compiler?
  • In reply to Markus Weiss-Ehlers:

    Hi Markus,

    the thing is we can not log on in any 1IM application, including the Database Compiler.
  • In reply to adrian.perez3:

    When you try to login with the Database Compiler, what is the error message?
  • In reply to Markus Weiss-Ehlers:

    Exactly the same error.


  • In reply to adrian.perez3:

    Wild guess. Are you running this on a 32Bit Windows?
  • In reply to Markus Weiss-Ehlers:

    Hey Markus. We are running this on a 64bit Windows.
  • In reply to adrian.perez3:

    Strange then. Did you check the eventlog? You should see more information about the error there. It might point you to the DLL that he is complaining about if it is not the VI.DB.dll.
  • In reply to Markus Weiss-Ehlers:

    The last info we get from the eventlog of the app is the following:

    2018-04-12 12:42:23.1441 DEBUG (StopWatch SW) : Getting MultiLanguageColumnDeps/global from cache. done in 0ms.
    2018-04-12 12:42:23.1441 DEBUG (StopWatch SW) : Getting CultureChain/en-US from cache. done in 0ms.
    2018-04-12 12:42:23.1441 DEBUG (StopWatch SW) : Getting MultiLanguage/QBM-D0A474E06FE2420D99D375DE94EB5CB3,en-US from cache. done in 0ms.
    2018-04-12 12:42:23.1441 DEBUG (SqlLog 8b3f683f-95f7-43eb-a098-7c5a60f2ea25) : (1 ms) - select a.AssemblyName, a.Class, a.InitialData, a.Caption, p.Ident_Product
    from DialogAuthentifier a with (nolock)
    join DialogProductHasAuthentifier pha with (nolock) on a.UID_DialogAuthentifier = pha.UID_DialogAuthentifier
    join QBMProduct p with (nolock) on pha.UID_DialogProduct = p.UID_DialogProduct
    and p.Ident_Product = N'Manager'
    and pha.IsInActive = 0
    where a.IsEnabled = 1 and a.Ident_DialogAuthentifier = N'DialogUser'

    I can not identify if the problem is for this query, because similar queries seem to work.

    I would like to raise my question again: It is ok to delete an entry in the DialogScriptAssembly table? Will it be created after compiling the DB again?

    And another question: Is there any way to compile the DB without logging in any 1IM application?

  • In reply to adrian.perez3:

    You should have checked the System or Application event log as these are .NET messages.

    No, there is no way to compile the database without accessing the database.

    You can delete the entries in DialogScriptAssembly, they will be re-created.

  • In reply to Markus Weiss-Ehlers:

    Yesterday we checked also those event logs using the Event Viewer from some servers and we didn't find any error regarding this problem.

    Also, we deleted that entry in the DialogScriptAssembly, but we got another different error that seemed that it was not a good idea and we came back to the previous state (with that entry in the table).

    Then, since this problem is becoming important, we contacted support. And if community members still have more ideas, feel free to share it here. If we find the root of this problem, I will try to keep you updated as well.

    Thanks one more time,