Error CLR_E_OUT_OF_RANGE

Archive
21

Thanks for your quick reply,
I am developping an application on EMX based board. with 3.5" LCD. (Some buttons, and graphical interface)
All was working fine, but I would now add more menus and then I get this CLR_E_OUT_OF_RANGE error.

So I try to understand what is the meaning of this error, what can cause it (how to know what is out of what range? what is the limitation? why? ) and how to fix it.

Seeing this post, I was first thinking that I had to split my assemblies , in case they are over some critical size, but it is not the good way.

An other idea is ā€œI had too many static variableā€ , wich seems coherent with this post : https://www.ghielectronics.com/community/forum/topic?id=12659

I will try tomorrow to replace static variables, if I can ā€¦ but I donā€™t really see why/what is the limitationā€¦ I donā€™t think it is hardware limitā€¦

22

What line of code gives you that error?

23

OK, my issue is fixed.
the ā€œI had too many static variableā€ statement was good.
I massively changed in my code static variables to const (I have a lot of strings and ints that are not modified during run time)
Then it allows me to declare new ones. This small test can help to point that there is a limitation of the amount of static variables . just add a lot of declarations of static ints, and the error ā€œ209 CLR_E_OUT_OF_RANGEā€ in file ā€œMPPā€ (Memory PP???) will occur. My code is several thousands line, so I will not post it there, but I am sure that this is pureley related to amount of static variables, but I canā€™t say how muchā€¦ maybe over 255?
@ Architect : This exemple can help to point the issue.


//Lot of other static variables before
//Testing limitations of static variables
        static int A1, A2, A3, A4, A5, A6, A7, A8, A9, A10, A11, A12, A13, A14, A15, A16;
        static int B1, B2, B3, B4, B5, B6, B7, B8, B9, B10, B11, B12, B13, B14, B15, B16;
        static int C1, C2, C3, C4, C5, C6, C7, C8, C9, C10, C11, C12, C13, C14, C15, C16;
        static int D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11, D12, D13, D14, D15, D16;
        static int E1, E2, E3, E4, E5, E6, E7, E8, E9, E10, E11, E12, E13, E14, E15, E16;
        static int F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11, F12, F13, F14, F15, F16;
        static int G1, G2, G3, G4, G5, G6, G7, G8, G9, G10, G11, G12, G13, G14, G15, G16;
        static int H1, H2, H3, H4, H5, H6, H7, H8, H9, H10, H11, H12, H13, H14, H15, H16;
        static int I1, I2, I3, I4, I5, I6, I7, I8, I9, I10, I11, I12, I13, I14, I15, I16;
        static int J1, J2, J3, J4, J5, J6, J7, J8, J9, J10, J11, J12, J13, J14, J15, J16;
        //uncomment the following lines causes the CLR_E_OUT_OF_RANGE error
        //static int K1, K2, K3, K4, K5, K6, K7, K8, K9, K10, K11, K12, K13, K14, K15, K16;
        //static int L1, L2, L3, L4, L5, L6, L7, L8, L9, L10, L11, L12, L13, L14, L15, L16;
        //static int M1, M2, M3, M4, M5, M6, M7, M8, M9, M10, M11, M12, M13, M14, M15, M16;
24

I ran into this problem about 6 months ago. Instead of addressing the issue I took advantage of the error to optimize my code. Eventually Iā€™d optimized things to the point where I had no options, so I broke my code out into multiple assemblies. This of course eliminated the CLR_E_OUT_OF_RANGE error.

Inadvertently the quality of my code has improved because of this issue. Iā€™ve split my code into a few assemblies, one for hardware abstracts, one for my UI and one for my controller (application logic).

25

Iā€™ve just ran into this issue today and it happened after I added additional glide components to a form so it appears that the resources have exceeded the limits.

I have 2 options.

I have considered moving some of the bitmap images to the SD card and load these when the programme starts. Trouble is I canā€™t see how to load the bitmaps. :frowning:

The second option is to break up the resources. Is this possible? Can I create a class that holds the bitmaps and then load them from this class?

26

@ Dave McLaughlin - I have never used itā€¦ but i guess a File.Readā€¦ and pass the buffer to the constructor of Bitmap (
byte[] imageData,
BitmapImageType type)

27

@ Dave McLaughlin - I reached this wall about a year ago (if itā€™s the same root cause)
For me it was the amount of IL code per assembly that is limited to 65K, I then split up my solution into multiple projects to overcome this limit.

28

Yeah, Iā€™ve spent the last couple of days doing that. It was a bit of work so late into the project but it means I have enough capacity left now. It would be good if the error actually indicate which part was too big :slight_smile:

29

Yes knowing more details about this error would be really helpfull. I think thereā€™s a log file where we can find more info but do not remember how to get itā€¦ :wall:

30

Does anyone know where this so called log file is located. I keep getting this error and it would help to know which file during the compilation has failed?

31

I have also got this error CLR_E_OUT_OF_RANGE in my project so I have created another 3 projects (as a class library) from my original big project and now I am able to compile without errors.
But I am surprise that now my code increased from cca. 335kBytes to 530kBytes(this is a values shown in VS output screen during deployment) after splitting my project what is annoying. I didnā€™t added any new code, only slitted my project.
What could be the reason of such a big increase of code amount?
Could it be e.g. redundant references used during splitting of the project?

32

@ mhstr - If your code is below the max size you should be fine, having references to the same DLL in multiple projects wonā€™t matter.

Resources are an issue too. Have any big resources or just a lot of them?

33

@ Skewworks - Actually I do not have any resources in the project. There was some small one and even I have erased it the size of deployed application is still cca. 530kByte although before splitting it was only cca. 335kBytes.

It is really strange that the size has been increased almost two times just by splitting. I do not have any experience with splitting one project to more so that is way I am wondering why the size is increasing although I have not added any additional code.

The problem is that every new version is sent to the customer and he uploads it to the G400 based PCB through built in FTP server. You can probably imagine that if the binary image increases almost two times then HEX file increases even more and the time for uploading 2-3Mbytes HEX file will be quite significant as the ENC28 Ethernet used with G400 is not so fast (my experience is cca. 40kBytes for file upload to the G400).
And we are planing to make an upload also through GPRS GSM modem so this is even slower mediumā€¦

I am still thinking how can the project splitting increase the application so much.

34

@ mhstr - are your figures from debug or release mode? I suspect there is overhead associated with each assembly.

35

While splitting wonā€™t affect the size loaded onto the device itself it will increase the pe size since libraries are included in the pe and therefore redundant. When it goes to the device, the redundancies are ignored. In the end the resultant HEX file shouldnā€™t see a significant increase from splitting.

36

@ Mike - it is from debug mode.

@ Skewworks - I have tried to generate HEX file by FEZConfig and the size after splitting is 1,5Mbytes while the size before splitting is cca. 1MBytes so there is a significant increase matching the increasing values of the application seen also in VS during deployment.

So what is the proper and recommend solution to eliminate CLR_E_OUT_OF_RANGE error without significant increasing of the application size?

37

@ mhstr - I believe that MF has a limit of about 64K of IL per assembly. You might want to split the current assemblies further. Split the one with the most code. I believe you could just add an additional DLL and move classes into the library without worrying about namespaces. Experiment a bit.

I would not worry about the program size. What is important is how much free memory exists after the program is loaded.

I would also try to see what happens in release mode.

38

I have tried to set all projects to Release mode and the result is almost the same - the size shown during deployment in VS is 513kBytes(against 335kBytes before splitting). The HEX file size is also almost the same - 1,5Mbytes.
So not so much difference between Debug and Release mode.

I will try to experiment more.

39

As Mike suggested, break up your project into libraries. I ran into this same issue very recently and by moving all of the data capture and processing into a class library I was able to build again with additional space for the main programme.

40

Thank you all very much for suggestions and time spent with this topic.

I am able to split the project to the sub projects and compile again without errors as I mentioned.
The sub projects are configured as Properties->Application->Output type->Class Library so I hope this is correct setting.

What I am still thinking and what is little bit strange to me is the size of the new application which is cca. 1,6 times bigger(also image HEX file) than previous not slitted project.
I have tried also to reference directly xxx.dll from sub project instead of all sub project but the result is almost the same(size is cca. 1,6 times bigger - also HEX image file ) so probably no matter if reference inside ā€œmasterā€ project is directly sub project name or itā€™s xxx.dll.
I have tried also to erase application and firmware from G400 by FEZ Config to be absolutely sure that I am deploying to the ā€œfreshā€ G400 and the size is also 1,6 times bigger.
I have tried to compile with project and all sub projects set to Release(instead of Debug) and the size has decreased only little bit.
There are no resources in the sub projects, only 3 Glide screens in the main project for T43 display.

@ Dave McLaughlin - In case you remember such a details about your application size do you have similar experience with the size before and after splitting?