Login Page - Create Account

Home >> Support Board

Support Board

Date/Time: Wed, 11 Nov 2026 18:07:51 +0000

How to Post a Message for Support

Setting study DLL module function objects to indicate DLL is not loaded

View Count: 337

[2026-09-24 23:48:29]
[Go To First Post]
User153286 - Posts: 73
This is not a coding/logic question, it is a process question with compile and load.


I have successfully built numerous custom study's that compile, load and work as expected. But recently and seemingly out of the blue I get
messages like this:

2026-09-24 17:06:05.085 | Setting study DLL module function objects to indicate DLL is not loaded: C:\SierraChart\Data\TestDLL.dll
2026-09-24 17:06:05.085 | Study DLL module not found for: C:\SierraChart\Data\TestDLL.dll

I am using the Analysis -> Build Custom Studies DLL ->Remote Build - Standard feature of SC. I have Windows 11 with the most recent updates and I am on SC Version 2953 64-bit, Revision 58206

I get no complier errors, just the listed error in the message log.

I have gone round and round with the help of Google Gemini to get to the bottom of this - deleting dlls, closing SC, rebooting laptop, changing name, etc... I have tried changing file name, dll name and study name, ensuring the naming nomenclature is as exactly as expected. Gemini compared a working study's code to the included test example finding no differences in the naming nomenclature. Furthermore even more strange is during all of this testing all my my other, existing studies compile, load and work without issue. It feels like I hit some internal limitation.

All source code .cpp files are in the ACS_Source folder
All DLLs get created in the Data folder
All DLL's automagically get an _64 on the end before .dll, for example : TestDLL_64.dll

Notice in the error, it's trying to load C:\SierraChart\Data\TestDLL.dll which has no _64.dll in its name

Yet check this out, from one of the other studies that works just fine:

2026-09-24 17:06:38.289 | Setting study DLL module function objects to indicate DLL is not loaded: C:\SierraChart\Data\ChartTitle.dll
2026-09-24 17:06:38.290 | Unloaded DLL: C:\SierraChart\Data\ChartTitle.dll. Handle: 7ff9fdf90000

See this in the message log indicates I will be able to find said study in the Custom Study UI.

ChartTitle is one that works just fine, it's dll does get the _64 stuffed in, SC indicates it is loading the non_64 name just like with the TestDLL study (see the above messages) yet with ChartTitle all works just fine where as with TestDll it fails.

TestDLL is just an example of a very simple study that does not work spewing the Study DLL module not found for, yet the dll is built the same way.

Futhremore, if I change it's DLL name from TestDLL_64.dll to TestDLL.dll (taking out the _64) it loads just fine and I find it in the Custom Study UI and works. If I leave the _64 in the name, which the is how the complier outputs the .dll, it fails.

Any idea what's up? Is there some limit to the number of .dlls somewhere? I have 20 custom DLLs in the data folder, each with their own study, its just how I developed they quick and easy. The are no duplicate study names, versions, etc...

Here is the TestDLL.cpp (the name is as used in ACS_Source folder), its really simple and don't really care what it does. I want to get to the bottom of why the compile, load process fails.


// The top of every source code file must include this line
#include "sierrachart.h"

// For reference, refer to this page:
// Advanced Custom Study Interface and Language (ACSIL)

// This line is required. Change the text within the quote
// marks to what you want to name your group of custom studies.
SCDLLName("TestDLL")

//This is the basic framework of a study function. Change the name 'TemplateFunction' to what you require.
SCSFExport scsf_TestDLL(SCStudyInterfaceRef sc)

{
  // Section 1 - Set the configuration variables and defaults
  if (sc.SetDefaults)
  {
    sc.GraphName = "Template Function";

    sc.AutoLoop = 1; //Automatic looping is enabled.
    
    sc.Subgraph[0].Name = "Name";
    sc.Subgraph[0].DrawStyle = DRAWSTYLE_LINE;
    sc.Subgraph[0].PrimaryColor = RGB (0, 255, 0);
    
    sc.Input[0].Name = "Float Input";
    sc.Input[0].SetFloat(0.0f);
    
    return;
  }
  
  
  // Section 2 - Do data processing here
  
  
}
Date Time Of Last Edit: 2026-09-24 23:53:56
[2026-09-25 00:39:32]
[Go To First Post]
Sierra_Chart Engineering - Posts: 25412
We are checking on this.
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing
[2026-09-25 01:20:06]
[Go To First Post]
Sierra_Chart Engineering - Posts: 25412
We are not able to reproduce this. We used the source code you gave above. The name of the source code file is TestDLL.cpp.

And this is the generated file name:
TestDLL_64.dll

This DLL did show up in the Add Custom Study window and we could add the study to the chart.

Look in your Data Files Folder:
General Settings Window: Data Files Folder (Global Settings >> General Settings >> Paths >> Files and Folder Paths)

What are the files that you see that begin with TestDLL?
Sierra Chart Support - Engineering Level

Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy:
https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation

For the most reliable, advanced, and zero cost futures order routing, use the Teton service:
Sierra Chart Teton Futures Order Routing
Date Time Of Last Edit: 2026-09-25 01:36:05
[2026-09-25 04:13:32]
[Go To First Post]
User153286 - Posts: 73
Possible solution:

Another point of interest, my charts are complex. I use my custom studies and I also use a lot of the utility type studies you provide allowing me to build output on the chart based on other studies and bar data in the chart. I typically have 5 charts up across 4 monitors. This may or may not be part of the issue but in hindsight I thought the complexity may be involved in the problem.

The real problem is I do not see the just successfully compiled study in the custom study UI, yet the DLL is in the appropriate folder with the magically applied _64 in the name.

Here are the messages I see in the Message View when this issue occurs for a specific study:

2026-09-24 17:06:05.085 | Setting study DLL module function objects to indicate DLL is not loaded: C:\SierraChart\Data\TestDLL.dll
2026-09-24 17:06:05.085 | Study DLL module not found for: C:\SierraChart\Data\TestDLL.dll


Previously I was doing my AI research on the 2nd message which was/is "Study DLL module not found for: C:\SierraChart\Data\TestDLL.dll"

I find it very weird that SC somehow magically adds the _64 to the DLL name, yet it appears to attempt to load the non_64 version instead as listed as for example seen in the "Study DLL module not found for: C:\SierraChart\Data\TestDLL.dll" message. But, if I rename that DLL, manually removing the _64 from the name, everything works. So be it, overcoming or accepting weirdness is part of development.

I then considered that perhaps the 2nd message is just an artifact of the real problem. So I changed the AI research to focus on the 1st message which is "Setting study DLL module function objects to indicate DLL is not loaded". The updated AI research came back with this:

if one is creating, adding, updating basically mucking with custom studies, try these 3 steps if you encounter the "Setting study DLL module function objects to indicate DLL is not loaded" message.

Step 1: Check File Locations
Step 2: Click on Allow Load DLLs
Step 3: Recalculate Chart


Step 1 I have done and verified numerous times. The file locations are correct, source is where it should be and DLLs are uploaded to where they should be from the Remote Build process.

Step 2 was new to me. I read up on Analysis-> Build Custom Studies DLL -> Build -> Allow Load DLLs I believe this is an internal magical SC process that runs when clicked on and is global in nature. I do not really see anything happen, it just seemingly does it's magic. Not certain if it only processes the selected file in the Build UI or not. It just quietly does what it does in the background.

Step 3 raised other questions for me. I have been reloading charts to pickup UI changes in updated studies. AI research indicated to only use "Recalculate Chart" from the Chart Menu in the affected chart when this issue occurs. But being global in nature and in hindsight I do not think it really matters what chart "Recalculate Chart" is invoked from. Only doing "Recalculate Chart" seemed to be the required final step that resolved the issue.


After doing these 3 steps with TestDLL, the TestDLL study magically appeared in Custom Studies UI.

Why this issue occurs with some studies and not others is a completely different question, perhaps you have some ideas why?

As I initially indicated, I provided TestDLL just to send in example study code. I have since applied the 3 steps to a real study I have been working on that initially ran into this issue. I had already run the 3 steps for TestDLL so I thought it might apply to my real study too, but after a recompile of the real study to re-create it's _64.dll file, the real study did not appear in the Custom Study UI and the 2 signature messages for this issue appeared in the message log. So I repeated Step 2 and then Step 3 and wala the real study appeared in the UI.

This whole experience/process seems very weird to me but it thus far works for my environment. Even more strange is that this issue does not seem to happen for all custom studies, just the lucky ones I guess.
[2026-09-25 16:43:55]
[Go To First Post]
User153286 - Posts: 73
And 12 hours later the above process did not work but seemingly for a very specific name, so weird. The name I trying to use was "MOBClusterVolumes" for the .cpp, SCDLLName and SCSFExport scfs_MOBClusterVolumes method name.

I did a grep in the ACS soure looking for "MOBClusterVolumes" in the .cpp file finding nothing

So I tried a different name for these. My initials are TLU so I use TLUTest for the .cpp, SCDLLName and method name. I used the same code within this renamed source, same exact code and it works. Since the MOB should be MBO, I set sc.GraphName in the TLUTest.cpp to "MBO Volume Clusters".

I now see TLUTest.dll in the Custom STudy UI and I able to add the study "MBO Volume Clusters"

Any idea whats going on?
[2026-09-25 17:05:01]
[Go To First Post]
User153286 - Posts: 73
last update for today... another strange finding.

With the above update, I had created TLUTest.cpp using the Analysis->New/Open Custom Studies File. And as I mentioned I copied all the wanted code fro the MOBClusterVolumes logic into it. It complied and worked using the 3 steps that I found last night.

So, I change the name of the my existing MOBClusterVolumes.cpp to MOBClusterVolumes_v1.cpp and removed it's _64 DLL in the Data folder

I then created a new MOBClusterVolumes.cpp file using using the Analysis->New/Open Custom Studies File. This builds a template which I then updated as follows:

// The top of every source code file must include this line
#include "sierrachart.h"

// For reference, refer to this page:
// Advanced Custom Study Interface and Language (ACSIL)

// This line is required. Change the text within the quote
// marks to what you want to name your group of custom studies.
SCDLLName("MOBClusterVolumes")

//This is the basic framework of a study function. Change the name 'TemplateFunction' to what you require.
SCSFExport scsf_MOBClusterVolumes(SCStudyInterfaceRef sc)
{
  // Section 1 - Set the configuration variables and defaults
  if (sc.SetDefaults)
  {
    sc.GraphName = "MOBClusterVolumes";

    sc.AutoLoop = 1; //Automatic looping is enabled.
    
    sc.Subgraph[0].Name = "Name";
    sc.Subgraph[0].DrawStyle = DRAWSTYLE_LINE;
    sc.Subgraph[0].PrimaryColor = RGB (0, 255, 0);
    
    sc.Input[0].Name = "Float Input";
    sc.Input[0].SetFloat(0.0f);
    
    return;
  }
  
  
  // Section 2 - Do data processing here
  
  
}

This complied cleanly and came up with the 2 error messages in the message log
so I then did the Step 2 Build->Allow DLL Load followed by the Step 3 Chart->Recalculate
and magically the study appeared in the custom study listing

Why would creating the file via Analysis->New/Open Custom Studies File have anything to do with this? The windows properties for all the .cpp files I have made this way or by a simple copy and paste are all the same, same everything in their respective file properties details. This is so strange....

So added there are now 4 steps to use step 0 is to first create the .cpp source file using Analysis->New/Open Custom Studies File

To post a message in this thread, you need to log in with your Sierra Chart account:

Login

Login Page - Create Account