Decisions Fails to Start with New Custom DLL

Decisions Fails to Start with New Custom DLL

Comments

  • Our QA server won’t start with my new version of our custom DLL with our SessionID auth.

    The DLL works fine in our DEV2, but SHM won’t start in QA.

    All that’s in the primary.log is this:

    [Log:0] [Info],10 Nov 2017 13:30:21,Thread 4,n/a
    [Message]:MachineName = DECBOB CodeRevisionNumber = 40504 LastBuildDate = 10/3/2017 4:18:31 AM IpAddress = Unknown
    [Log:1] [Warn],10 Nov 2017 13:30:21,Thread 4,BootInitialization
    [Message]:No policy registered, setting Default License Policy.
    [Log:2] [Error],10 Nov 2017 13:30:24,Thread 4,Server
    [Message]:Error executing boot step DecisionsServiceHost.BootInitializers.SyncServerResources
    [Exception]:System.NullReferenceException: Object reference not set to an instance of an object.
    at DecisionsFramework.ServiceLayer.Utilities.ServerResourcesUtilitites.SyncLocalModule()
    at DecisionsFramework.ServiceLayer.Utilities.ServerResourcesUtilitites.SyncServerResources(Boolean syncCodeBucketAssembly, Boolean syncLessStyles, Boolean syncLocalModule, Boolean syncOtherModules)
    at DecisionsServiceHost.BootInitializers.SyncServerResources.Initialize()
    at DecisionsServiceHost.Instances.Implementations.BaseInstance.ExecuteBootInitializableStepAndCheckRestart(IBootInitializable bootInitializableStep)

    Progress.txt stops at this line.

    Sync Server Resources

    Tried multiple times. Any hints what to look at?

    Thanks.

  • Hi,
    Check that the dll is NOT blocked by windows. You can run the localsmodule reset utility.
    Thank you.

  • Hi,
    The file wasn’t blocked, but running the localsmodulereset utility fixed it.
    Thanks for the tip.
    What exactly does the utility do? Try to reason why it worked on DEV2 without running localsmodulerest, but we had to on DEV1 and QA.
    Thanks!

  • The local module files get imported into the database so that they can be replicated in a cluster and resorted if there’s any corruption.
    Sometimes we see the database dll as being newer than the one you’re dropping off so we ignore the one you’re dropping off.
    The reset utility flags the dlls as requiring import.

  • Where are the DLL references in the database? Ive got a similar issue, but I would like to remove the custom DLL altogether. When I delete the physical file, it reappears when the service tries to restart.

  • [quote=ChrisMazur]Where are the DLL references in the database? Ive got a similar issue, but I would like to remove the custom DLL altogether. When I delete the physical file, it reappears when the service tries to restart.[/quote]

    Got this from Support...

    Okay there is a way to do this, but we have to delete directly from the Decisions database.

    1.Stop service host watcher and service host manager
    2. Delete dlls from Service dlls directory including temp folder
    3. Find and delete the dll from repository_resource table
    4. Find and delete the dll from module_resource_service_lib table
    5. Start shm watcher

    The dll should not reappear.

  • For those looking for answers in this post, we have an updated solution to removing custom DLLs that can be found at: https://documentation.decisions.com/docs/troubleshooting-a-custom-dll-file.

    For issues that may involve directly modifying the database, please contact support before doing so at support@decisions.com.

Sign In or Register to comment.