none
Runtime exception dependent upon build PC RRS feed

  • Question

  • I have two Build PC's running Windows XP that I have installed VS2005/Platform Build CE 6.0 R3 in the exact same manner.  When I build our application code and a CE image with it on PC #1, the resulting nk.bin runs properly on our target hardware.  But, when I build our application code and a CE image with it on PC #2, the resulting nk.bin exceptions (see below) on our target hardware.

    From the reported exception, it appears that the exe runs out of stack space so I increased the stack from 64 to 128 kB.  After rebuilding the application code and CE image, the new nk.bin runs properly on our target hardware!  This is quite surprising to me and I wonder if anyone has a good explanation for this.  Unfortunately, it indicates that runtime behavior is very dependent upon the build environment, even when the tools are installed the same.

    BillT  

    !!! Committed last page of the stack (0x00060018), SEH bypassed, thread terminated !!!
    Exception 'User Stack Overflow' (-3): Thread-Id=0419000e(pth=83b9bda4), Proc-Id=0418000e(pprc=83b9ba90) 'ALARMMANAGER.EXE', VM-active=0418000e(pprc=83b9ba90) 'ALARMMANAGER.EXE'
    PC=400246a2(coredll.dll+0x000146a2) RA=40024a19(coredll.dll+0x00014a19) SP=0006eee4, BVA=00060018

    • Moved by Jesse Jiang Friday, June 24, 2011 8:21 AM (From:Visual Studio Smart Device Development - Native C++ Project)
    Wednesday, June 22, 2011 2:11 PM

All replies

  • Hi ,

     

    I think your issue should be raised in the Windows Embedded Compact Platform Development. I believe they will know more information of this issue than us, and I will move this one to that forum.

     

    Thanks for your understanding,

     

    Best regards,

    Jesse


    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, June 24, 2011 8:21 AM
  • Do you mean that 2 PC with the same tools configuration (QFEs included), the same BSP, OS project and application subproject produce 2 nk.bin which behave differently on the same target HW? If this were true it would be frightening!

    Comparing the 2 nk.bin you will find some differences (timestamps, etc) in any case so I would compare ce.bib, reginit.ini, ceconfig.h  and SysgenSettings.out  of the 2 %_FLATRELEASEDIR%. If those aren't different I would compare the files in the 2 %_FLATRELEASEDIR% to check if one or more have a substantial difference in size.

    I would even check that the two Windows XP are at the same level respect to the Windows Update.

    I really think that there's something different between the development environment, it must be something different otherwise all the different developers in the world would be at mercy of fate...

     

     


    Luca Calligaris lucaDOTcalligarisATeurotechDOTcom www.eurotech.com Check my blog: http://lcalligaris.wordpress.com
    Friday, June 24, 2011 12:00 PM
  • You might try checking the stack size at run time on the two images.  It is possible that there is something in your environment that is causing the default stack size to be different.  I haven't done it, but I think you can get the stack size from the TLS; see UStkSize() definition in pkfuncs.h
    Dean Ramsier eMVP BSQUARE Corporation
    Friday, June 24, 2011 12:58 PM
  • I performed the comparisons that you suggested and have investigated this further.  What I found is that there were no differences in the ce.bib, reginit.ini, ceconfig.h or Sysgensetting.out files for the same OSDesign on the two build PCs. And, when I compared the nk.bin's in VS2005 (#1), it also reported no differences.  But when I manually diff'ed all the files in the reldir, there were differences in the application code exe/dll files built by VS2005.

    Our application does quite a lot and consists of 11 exe's and 60 dll's.  We have an automated build processs that builds the application code in VS2005 and then builds the CE image.  This process 'gets' all source code from our Software Configuration Management system and builds everything by executing a single script.  The same scripts and source code were used on both Build PC's so it now appears that something may be different in the VS2005 installs.  BTW - 43 of the 71 application exe/dll file differ (most in size) between the two builds.

    Is there any way to compare installation, options settings, etc.?

    #1 - I am surprised that VS2005 did such a poor job of comparing the two bk.bin's when the differences were so dramatic. 

     

        

    Wednesday, June 29, 2011 1:01 PM
  • VS comparison of 2 nk.bin does a good job for the registry while, for the files, it tells you only if a file is present in one nk.bin but not in the other without checking the size of the files


    Luca Calligaris lucaDOTcalligarisATeurotechDOTcom www.eurotech.com Check my blog: http://lcalligaris.wordpress.com
    Wednesday, June 29, 2011 2:06 PM
  • Again, I recommend you check the stack size at run time.  If it is different on the two images, that will give you an avenue for investigation.
    Dean Ramsier eMVP BSQUARE Corporation
    Thursday, June 30, 2011 1:00 PM
  • I modfied our code to report the stack base and size and was able to build it on the system that produced the exception.  The proper stack size was reported by the app when set for both 64 KB and 128 KB even thought it excpetioned when set for 64 KB.

    Next we will try it on the buiild PC that produced the exe that did not excpetion.  Its stack size is also set for 64 KB.

       

    Friday, July 1, 2011 12:08 PM
  • You might also want to try the CEDEBUGX stack analysis tool to make sure the stack is being used as you would expect.  See http://msdn.microsoft.com/en-US/library/ee481435(v=WinEmbedded.60).aspx

     


    Dean Ramsier eMVP BSQUARE Corporation
    Friday, July 1, 2011 2:26 PM
  • Thanks Dean, this looks promising.  I am out for a week of vacation and will give it a try when I get back.  
    Friday, July 1, 2011 3:57 PM