I have an app which uses Boost libraries. On Desktop, the Windows UAP application works as expected, however, on phone (real phone or emulator), the app crash on start, and it is not possible to debug.
It seems the issue comes from the boost::thread library.
Here are simple steps to reproduce this issue:
Build boost thread and date_time (date_time seems required to link) from the command line with: b2 --with-thread --with-date_time toolset=msvc-14.0 variant=debug link=static architecture=x86 windows-api=store cxxflags="/AIC:/winrt". Note that "C:/winrt" is a junction to "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\store\references" where platform.winmd is (since it seems required to build)
Create a Blank C++ Windows 10 Universal app using Visual studio 2015.
Edit Mainpage.xaml.cpp and add a call to boost::thread like: boost::thread workerThread(workerFunc); where "workerFunc" is whatever function you want. Add the required include file ( #include <boost/thread/thread.hpp> ). In the link option, add boost thread lib.
Now run the app in a phone emulator.
Result: the app will crash at load time.
This happens on real phones with arm CPU too (with boost built with option architecture=arm). This issue can't be reproduced on desktop computers using the same app built for the emulator. Just run the app on your locale machine and it will work.
Am I missing something?
The issue seems to be that Windows UAP projects link by default with library which are not available in phones, like ole32.lib. So it compiles and work on desktop, but crash on phone, and there is no information about which dll creates the issue. Furthermore, the app validation software from microsoft doesn't provide any information about that.
I was also facing similar issue , app works fine in desktop but fails to load in windows phone emulator. I ran the certification toolkit and found out app is using restricted api (CryptGenRandom in advapi32.dll) which boost was using. removing that particular function call resolved issue.
Related
I've tried using the standard Blazor template app to remote debug on an Azure app service and I get the following error:(the app run fine if a compile to release, though not debugging of course.)
I compile to debug any CPU.
UPDATE
I can debugger in my .razor pages.
PRIVIOUS
Judging from your error message, the problem may be caused by unsuccessful release of some files and other factors when the program was released.
In order to solve your problem, you can tell us the version of Visual Studio you are using and how you created the project. This problem is mostly related to your development tool environment configuration.
Here is a suggestion, test it by yourself and it runs normally.
Visual Studio 2019 Enterprise Edition (other versions should also be normal)
Configuration before project release
Start remote debugging
The final result
I have universal project targeting Windows Store 8.1 and Windows Phone 8.1 platform.
The windows one works fine but I having trouble running the WP one on an emulator. I get the error message saying:
Microsoft Visual Studio Unable to activate Windows Store app
'numbers-here!App'. The Kiss.WindowsPhone.exe process started, but the
activation request failed with error 'Msg in polish that the app did
not start'.
If this was Windows I would check System Event Log and see the logs just before the error what DLL the system was trying to load and that helped a lot when I was debugging similar problem with Windows Store project, here I have no clue on how to check what exactly was being loaded.
The worst part is that I created package (appx) and checked the dll's being packed with exe, it seems that it includes dependencies that the app explicility uses yet something is still missing and this might be some 'hidden' dependency of one of the other dlls.
Any ideas how to debug such issues with emulator?
For me it was due to having WIC code in my App and/or calling CoCreateInstance in a windows phone environment ( on PC it works flawlessly though )
I ran into the same problem on Windows 10. Turns out, that there is no Kernel32.dll on Windows 10 phone!
Instead you need to link against OneCore.lib which provides the entire Win32 API subset that is supported in UWP. This "umbrella library" will load the correct dlls at runtime.
See also:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt683763(v=vs.85).aspx
I have been using MonoDroid in Visual Studio 2012 to create an Android app and everything works fine. I can publish the app to my phone and everything works fine (both debug and release builds). However, when I try to have MonoDroid create a .apk file I get the following error:
System.Exception: The "ResolveAssemblies" task's outputs could not be retrieved from the "ResolvedAssemblies" parameter. Parameter "includeEscaped" cannot have zero length.
Does anyone have any idea how to fix this?
Well, it turns out that Xamarin themselves believe I should do it manually. Guess this is not a high priority.
I'm trying to use EQATEC Profiler to profile my ASP.Net app. I am following the below steps to do it. I have selected the application's bin folder in App path and clicked on the build button. Then I have run the application from visual studio 2005. However, i don't see the reset counter or take snapshot buttons enabled. Please help.
You'll find a nice step-by-step instruction and explanation in this thread.
I may also have an explanation of what's going wrong for you:
You compile your asp.net app in VS2005 - fine
You then instrument and overwrite your app using Build in the profiler - also fine
But then you run your app from VS2005 and that may re-compile your app again so you're running an un-instrumented version. Instead of running it from VS2005 you should simply have IIS "launch" the code by navigating to the corresponding webpage.
If this is not the problem then take a look at the log-file generated by the running, profiled app. By default the log-file is located in C:\Windows\Temp\EQATECProfilerLogs\profiler.log.
Does a System.Runtime.InteropServices.COMException of 0x80040154 always mean that the class isn't registered? I'm getting a COMException which says "Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following error: 80040154." It's trying to load Interop.Domino.dll which is a reference I got from the COM tab of Add Reference called "Lotus Domino Objects" which points to domobj.tlb in the Notes program folder.
I wrote the code years ago - it's the only thing I've ever done with interop and it's fair to say that I never really got to grips with it.
I'm seeing this error again after moving the code to a 2008 R2 server (so it's x64). It was written on XP and run on 2003 (both x86). In order to diagnose the problem, I built a Win7 x86 (because there's no R2 x86) box and it worked. I also built a 2003 x64 box and it fails with the same error, so it looks like it's caused by moving to x64 architecture. Is there something I should do when doing interop to get x86 COM DLLs to work on x64 machines?
I had the same problem trying to build and run a .NET application on Windows 7 x64 that called interop.domino.dll, which is 32 bit only.
To resolve, I recompiled the .NET application to run specifically as x86 when run on x64 operating systems.
I was using Visual Studio 2010 Express Edition which is trickier to target specifically for x86 platforms than the paid for versions.
The solution was:
Click TOOLS > OPTIONS > PROJECTS AND SOLUTIONS
Check the box "Show advanced build configurations" and click OK
Click TOOLS > SETTINGS > check EXPERT SETTINGS to see the build configuration manager
Click BUILD > CONFIGURATION MANAGER select the platform dropdown to X86 and click CLOSE
Now rebuild the project
Pay attention to register of 32-bit components using the correct register (C:\Windows\SysWOW64\regsvr32.exe).
If you have already registered up with the 64-bit version, unregister each dll with the same version.
More help you find here Team is Going from XP32 to XP64 for .NET Development - Any Gotchas?
Good luck
There's an IBM technote that indicates that the Domino COM classes are not supported on a 64-bit OS. See https://www-304.ibm.com/support/docview.wss?uid=swg21454291 So it seems like even by compiling the code to run as x86 (as per mpownie's answer), you're still taking some chances.