CreateThread ERROR_NOT_ENOUGH_MEMORY wince 6.0 RRS feed

  • Question

  • Hi all,


    We are developing a device wich uses Wince 6.0 as operating system.

    We have several applications, and we are able to make them run in our device succesfully.... since our last change.

    We have developed a driver which uses RNDIS functionality over the USB connection to simulate a serial port, sending to user the information provided by the applications via a socket connection.

    After including this driver in our image, we have started to experience some strange behaviour on the device. 

    Our applications are developed using Visual Studio 2005, and we have two different possible compilations for each one, a debug compilation and a release compilation. The only difference is that in debug mode, we tell que compiler to generate the debug information needed to use breakpoints during debug.

    Well, after this short intruduction, here are the strange symptoms:

     - If we deploy an application from Visual Studio, in release mode (without debug information), the application runs successfully without problem.

     - If we deploy the same application from Visual Studio, in debug mode (with debug information and breakpoints), the application fails in some CreateThread calls returning error 8 (ERROR_NOT_ENOUGH_MEMORY). Some other CreateThread calls before these success. For some reason, these calls in debug mode are failing and i cannot wonder why...

    For more information, i've developed a small test application which creates over 300 threads, and ran it in debug mode (with the same configuration which is failing in other applications). This application was able to create all the threads without problem, so, i suspect that in the end it won't be a memory problem...

    Taking a look at the new driver added to our image (after such addition the problems began), it is a stream monolithic driver. In it's _open function one thread is created which creates two more threads. But i think the thread creation in the driver is not the problem because if i comment out the lines of driver creation in the driver, i have the same problem. 

    The most interesting thing is that i have the same problem even without the driver being used by any application. Right now i have an application which doesn't use this driver, but it is failing anyway.

    As you can see i am a little bit lost. I hope my question is well understood. Sorry for my english.


    Any help would be appreciated.

    Best regards.

    Thursday, November 4, 2010 3:55 PM

All replies

  • When the failure occurs, how much memory is available?
    Bruce Eitman (eMVP)
    Senior Engineer
    Bruce.Eitman AT Eurotech DOT com
    My BLOG

    Eurotech Inc.
    Friday, November 5, 2010 10:52 AM
  • Hi Bruce,


    First of all, thank you for your reply.

    I must tell you that i've found that not all that i said in the last post was true. I've found a difference between the debug compilation and the release compilation. In debug we execute the next code:


    Which is not executed in release mode.

    As i've seen in the msdn web, this function is used to specify the number of pages to allocate for the object store. I have not developed the application, and i don't know why this code is here, but it seems it is used in the system initialization (in release mode another application which is executed before is which will execute this code, that's why this application only executes this code in debug mode).

    At this point, we must take into account two important things:

     - The msdn says that this function is deprecated. When do we need to use it? is there some other choice? Which size is assigned to the object store by default? What could happen if we don't modify the object store size?

     - Before adding the own developed driver, there was no problem executing this application in debug mode. So the driver addition must have changed something, but i cannot figure out what...


    As you can imagine, if i comment this code in debug version, the applications runs successfully.


    About your question, the memory parameters before executing the application (as seen in the performance monitor) are:

     - Available pagefile: 0

     - Available physical: 15548416

     - Memory load: 47

     - Total pagefile: 0

     - Total physical: 29286400


    For some reason, while executing the performance monitor, Visual Studio is not able to connect to the device to debug the application, so, i've executed it via a telnet connection. When i execute the application in release mode, the only parameter that is changing is the Available physical, which goes down to 3702784.

    When i execute the application in debug mode, performance monitor stops, and the whole system stops too (maybe due to the SetSystemMemoryDivision call...).

    The strange thing is that sometimes this call success and then the problem comes on the later thread creation as i explained in the previous post.


    Do you have any idea on what's happening?


    Thank you very much.


    Best regards,





    Friday, November 5, 2010 1:34 PM