Access violation write to 0x769896FB in ...indy.ex4 - page 2

 

Are you running terminal as Admin? 

"does this mean we no longer able to run multi time frame indicators ? ", I guess so

Do a bar count for the timeframe your getting the data input for the buffer. Make sure it isnt bigger than the bar count for your current chart, if its smaller then the use the shift to sync, if its bigger which isnt usually true of bigger frames then it may not be possible. You can use a different timeframe when inserting the OsMa onto a chart. Infact i tried the code and i didnt get a error which is bizarre, all implementation of the platform should have the same built in functions so we should have no difference.  

Have you got a memory scanner / hex editor and debugger like good old cheat engine? That will show you what is giving the error. 

 
Keelan:

Have you got a memory scanner / hex editor and debugger like good old cheat engine? That will show you what is giving the error. 

Unfortunately terminal.exe has a protection (or better) debugger detection embedded in the protection mechanism they use. Therefore the idea with using a debugger and getting a stack trace / back trace (including programm counter)  won't work (that easily). I remember having tried messing around with ollydbg a couple of years ago to debug some random annoyances that occoured with terminal.exe and failed. It took me a while to bypass (and understand) the debug protection. Later on discovered that terminal.exe also shifts their entire code from one memory segment to another. Unfortunately I initially came from 68000 programming and thus resigned because I didn't understand the x86 protection schemes and because of the overall time spent. Better results would probably be using a hardware debugger. A different approach would be to not care about the protection at all and dump the running process from start- to endaddress. Sadly this is a non option to debug code because you basicly freeze a running process where all variables, addresses and registers have been set to a defined state (before the freeze). Well that's all a couple of years back...

 

The above with simple words: Forget using a debugger in this case, because the time and efforts spent would be huge and totally irrational.

Reason: