User profile for 42vogons

If I run the x86 (working) case the ANTS log is as follows: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 19 Jan 2010 12:35:43.327 [1] INFO RedGate.Profiler.Logging.LogService - Starting new ANTS Pe...

0 votes

Chris, I think the mystery is partially solved, though the solution is not clear. I am running on x64 Windows 7. If I compile my executable in 'x64' or 'Any CPU' then it crashes when loaded under ANTS and touches the Unity .ctor. If I compile my executable in 'x86' it works under ANTS. This seems to be the case regardless of whether I compile Unity 'Any CPU' or x86 specific, and only seems to pertain what platform the executable was compiled to. So I believe my other console was working accidentally because it was compiled with 'Mixed Platforms', and in fact has nothing to do with the pipeline builder. So now that I know about this problem, what is the solution? I did not knowingly install an x86-only version of ANTS. It does appear to have installed under the native 'C:\Program Files', as opposed to 'C:\Program Files (x86)'. When I run the profiler I see "RedGate.Profiler.UI.exe" without the splat "*" suggesting it is running x64 native, and when I run my test program again I see "UnityUnderANTS.exe" without the splat "*" (however if I run "UnityUnderANTS.exe" compiled to x86 then of course the process is listed with a splat "*", indicating it really is running in the 32-bit WOW). Finally, I see ANTS knows something about x64 since it has an x64 folder: C:\Program Files\Red Gate\ANTS Performance Profiler 5\X64 It is, unfortunately, not a good solution for me to force my 64-bit application to 32-bit. Any thoughts on how to help ANTS along in this regard? Thanks! / comments

Chris, I think the mystery is partially solved, though the solution is not clear. I am running on x64 Windows 7. If I compile my executable in 'x64' or 'Any CPU' then it crashes when loaded under A...

0 votes

Chris, thanks for your reply. Us Douglas Adams fans have to stick together ; ) This problem appears in both debug and release mode. It only seems to occur when you choose â€œLine-level and method-level timingsâ€, which sadly is what I need. The fact that one of my consoles works perfectly and one fails is baffling, considering that the simpler of the two manifests the problem (wouldnâ€™t you think that the complex one would be more likely to break LOL). I donâ€™t believe this is caused by a corrupt PDB since I was able to readily reproduce the problem in a new project by creating a simple wizarded console using the C# code I showed in the first post there, and as I mentioned it still happens in both debug and release. Iâ€™m using Visual Studio 2008 SP1 to build the project(s) on and x64 machine, all assemblies configured for â€œAny CPUâ€ - and even on the off chance that the pre-built Unity assemblies might be the problem I downloaded the source and built them myself â€“ even when I build the project with the actual unity source, attach to the project with a debugger when itâ€™s loaded by ANTS but before the Unity .ctor and then attempt to step into the Unity .ctor â€œUnityContainer unity = new UnityContainer();â€ it crashes immediately with: System.TypeLoadException occurred Message="Bad unmanaged code entry point." Source="Microsoft.Practices.Unity" TypeName="<Module>" StackTrace: at Microsoft.Practices.Unity.UnityContainer..ctor() at UnityUnderANTS.Program.Main(String[] args) in C:\Temp\UnityUnderANTS\UnityUnderANTS\Program.cs:line 16 InnerException: I have carefully examined the build settings for the unity assemblies and they look like entirely typical pedestrian assemblies to me. If you run that sample project I posted under the debugger only and look at the loaded modules in the debugger hereâ€™s what it lists: - Mscorlib.dll - UnityUnderANTS.exe - Microsoft.Practices.Unity.dll - Microsoft.Practices.ObjectBuilder2.dll Again this doesnâ€™t look especially fishy to me. I can even force the Unity assemblies to load first as follows: Assembly.Load(AssemblyName.GetAssemblyName(Path.Combine(AppDomain.CurrentDomain.BaseDirectory,"Microsoft.Practices.Unity.dll"))); Assembly.Load(AssemblyName.GetAssemblyName(Path.Combine(AppDomain.CurrentDomain.BaseDirectory,"Microsoft.Practices.ObjectBuilder2.dll"))); This works fine, even under ANTS - until I try to new up Unity, and then it still crashes as before. Finally, if I attach to the project with a debugger when itâ€™s loaded by ANTS but before the .ctor and then set breakpoints both in the Unity .ctor and its base I donâ€™t hit those breakpoints â€“ itâ€™s like something lower level is crashing me. As to your other question, I donâ€™t use Unity in any different *way* between either of my console applications â€“ they both allocate a container using â€˜newâ€™ as shown above. One big endemic difference though is that the â€˜workingâ€™ scenario uses the .NET Application Extensibility namespace (described here http://msdn.microsoft.com/en-us/magazine/cc163476.aspx). Each AddIn loaded in my pipeline builder still â€˜news upâ€™ a Unity container though. Clearly something about the context in which my AddIn is called by the pipeline builder is serendipitously making this work. I did try one last experiment of creating a new AppDomain and then allocating my unity container inside a new AppDomain (as thatâ€™s what happens with the pipeline builder) but that did not work either â€“ so something else about the pipeline builder is magic besides its use of AppDomains. / comments

Chris, thanks for your reply. Us Douglas Adams fans have to stick together ; ) This problem appears in both debug and release mode. It only seems to occur when you choose â€œLine-level and method-l...

0 votes

Profiler crashes when using Unity 1.2 application block

I am presently using ANTS 5.2.0.26 to profile two applications - both run as a console and both use Unity 1.2. However, the simpler of the two crashes immediately when loaded under the profiler (an...

2 followers 9 comments 0 votes

How can we help you today?

42vogons

Activity overview