Attemp to use MSIL code from this assembly...

Attemp to use MSIL code from this assembly...

• Ben Andrews

  I'm trying to debug my application now, and I have "some" bugs.
  especially in the sprintf_s function.
  
  Like:
  
  

  void ST_GetCPUSpeed(LPTSTR txt)
  {
  sprintf_s(txt,sizeof(txt),"%ld Hz", 1000); // just a sample
  }
  
  But when debugging the application I always come to some other source files that have nothing to do with my project. How can I detect the bug in in MY source code
  

  
  

• LuisNeto

  With the bug in the code above there is not much that a compiler or code-analysis tool can do (OK: maybe a very specialized code analysis tool with a lot of context could work-out that in the context of the second argument to sprintf_s applying sizeof to a pointer is not the correct). In general you just have to step through the code, either in a debugger or in your head, and validate that every statement and expression is correct.
  
  I find that clearing my head of all thoughts about what I intend the code to do and just reading the code statement by statement and expression by expression (sometimes out-loud - with the office door closed ) can help me find logic errors in my code.

  
  
  

• Karthik B

  I have the same problem in an extension DLL compiled with /CLR option. I have a class which specialize the MFC CTreeCtrl class (to add new functions). I have the same warning LNK4248: unresolved typeref token (01000013) for '_TREEITEM'; image may not run .

  I add the /DSTRICT option in C/C++ command line but I still have the problem !

  If I add #pragma unmanage at the top of the .cpp source file, the link is OK.

  Does someone knows why the /DSTRICT don’t work and what is the best solution between the /DSTRICT and #pragma.

  Thanks in advance.

  Francois.

  
  

• CoolSniper

  You can add any compiler switch to the compilation command line by doing the following:
     1) Right click on the solution and pick properties.
     2) Click on "Configuration properties"->"C/C++"->"Command Line"
     3) Add /DSTRICT
  
  As for the #pragam unmanaged, I believe adding the pragma before the DllMain should resolve the issue.
  
  Hope this helps!
  
  Thanks,
    Ayman Shoukry
    VC++ Team
  
  
  

• MARViN2003

  The first issue is due to the fact that in both C and C++ the following is a valid, though pretty meaningless, program:
  
  class A;
  
  A* f(A* pA)
  {
     return pA;
  }
  
  int main()
  {
     A* pA = f(0);
  }
  
  Both C and C++ don't care that there is never a definition for A. The CLR is different as it is a much richer runtime it expects that it has type-information for every type that appears in the program. The error you are seeing is from the linker and it is complaining that while it has found references to the specified types it hasn't found a definition. As these are Win32 handle types the solution is to compile your program with /DSTRICT this will ensure that these handle types have a proper definition.
  
  The second problem is due to the fact that the CLR has detected that your program is attempting to run managed code either directly or indirectly from DllMain: this is a big no-no in the CLR as it can lead to loader-lock. The following article discusses the problem and how to get around it:
  
  http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnvs05/html/debgb1LdLk.asp

  
  
  

• huangmaoyi

  Sorry, but where do I set the /DSTRICT switch
  And what if I set ALL my functions to
  #pragma unmanaged
  Will that help me
  
  
  
  

• Ovesen

  That was NOT the answer I wanted
  With about 500 000 lines of code that may take a long time and inflammation of the throat .
  
  Are you sure, why can't the debugger point out MY source code. Is there any settings that I can exclude external files
  
  Pointing the debugger to:
  dbghook.c:
  void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
  {
  (_Reserved);
  _debugger_hook_dummy = 0;
  }
  have absolut NO meening for me (and others)
  
  AND the best of all: It's a multithread application.
  

• msw

  The problem is that in general the debugger sees your program as one monolitic executable (especially with native code and especially if you use static linking) and as such it can't easily tell your code from system code.
  
  One trick I use is to remove the location of CRT sources from the list of source file locations that the debugger uses to find the source code for a particular function. If the debugger cannot find the source code for a particular function it is not so enthusiastic about stepping into it.
  
  On the more general problem of finding bugs you need to narrow down the problem to a smaller set of functions. If I am debugging a problem and I have no idea where in my program the problem might occur I start by using the Step-Over functionality and stepping over function calls - if I spot that the program has gotten into a bad-state (usually I have something in the watch window that shows me the problem: or I have asked the debugger to halt if an exception is raised) then I restart the program and this time I Step-Into the function that caused the problem instead of stepping over it. I then repeat the process gradually narrowing down the scope of the problem until I arrive at the function where the problem lies.
  
  To speed up this process I make liberal use of break-points - i.e. if I know that the state of the program is correct at some point then I set a breakpoint at this location so I don't have to step through a lot of proceeding code: for long running applications I also insert calls to DebugBreak() at "interesting" points in the code - this allows me to start the application as normal and then when it hits the "interesting" point in the code I get a pop-up and I can attach the debugger and then continue the application, under the debugger, from that point.
  
  Conditional break-points are another great tool (for example: break on the 10,000th execution of this line) as are data break-points (for example: break when this memory address is written to).
  
  
• Attemp to use MSIL code from this assembly...