I have a code base of native C++. Recently I incorporated a Windows 8 tablet into the system that we deploy to.
I have a .NET managed DLL that accesses the Tablet orientation sensor. This managed code is wrapped by an unmanaged class that I can access from the native C++.
The problem is that I cannot run and debug the code on my Windows 7/VS2010 box without getting an Access Violation at the outset. No breakpoints are even hit before the exception.
Is there a way to ignore the managed DLL while debugging on the Windows 7/VS2010 box?
Delay loading is your friend. Read the MSDN documentation, starting with Linker Support for Delay-Loaded DLLs.
Related
I have a requirement to develop a SDK(kind of class library) for Windows app supporting Windows 8.1 and Windows universal apps. Please suggest me the right type to choose for this.
At first I was thinking to use Portable class library supporting these 2 platforms but later on some researching found out Windows Runtime component(Universal apps) and read that using this would support app build using non managed code too(C++, JavaScript) which kind of seemed good for me. but when I try to refer this into a windows 8.1 app it says not supported, Do I need to build a separate windows runtime component again for this(I see Windows runtime component(portable for universal windows 8.1 template)?
Is there any chance I could build this without the need of having 2 projects for different platforms?
I've been able to successfully use a WinRT component targeting Windows 8.1 in a Windows 10 app before, but it might have changed and YMMV. Try it out.
I have developed an MFC SDI app, which uses the default CDocument Save, Save As and Load Menu Options. When I run this app on Windows XP, Vista, or 7 the app works fine - it can save and load documents without issue. When I run the same app on Windows 8 or 8.1 and click the Save option, the app crashes with a generic error message. Is there something extra that I need to install for it to work on Windows 8? Or is there something special I need to do to get an MFC SDI app to work on Windows 8?
I have tried to install Visual Studio on the Windows 8 machine to compile it there but I only have the Express version, which doesn't come with the MFC libraries, so it will not compile. The PC I wrote the app on, was a Windows 7 pc.
I am not too sure what other information might be useful.
EDIT:
The error message
I have managed to compile MFC applications in older versions of Visual Studio Express, see:
http://www.codeproject.com/Articles/30439/How-to-compile-MFC-code-in-Visual-C-Express
To get this to work in a recent VS Express will probably require some tinkering.
I am working on a plug-in for an application. I have old development tools that have problems. My development tools are all from old 32 bit versions. CodeWarrior 6.7.and 8. I am running windows 7 pro 64 bit and having problems with the old tools. The CodeWarrior debugger will only work one time and I have to reboot before it will work again. It also has some problem using it. Break points stop working.
I switched to UeStudio from IDM but can not get a debugger to work. I created a project to use the compilers from Microsoft Visual Studio 10.0. UeStudio is supposed to use an integrated debugger. It downloads WinDbg.exe but it wont start up. The only WinDbg I found on Microsoft is from the Debugging Tools for Windows (x86) and (x64). It does not integrate with UeStudio. It starts up in a separate window. I have played around with it a bit but can not get it to load my DLL. I keep getting and error that it can not load my symbols (mismatching symbol file). I have set it to look were the '.pdb' for my plugin is located an doubled checked that it is correct. It's message names my DLL. I do not have symbols for the application. They do not supply one. I can load my source file and set Break points. But can not examine data.
Anybody get UeStudio debugging to work on windows 7? Or have any idea on debugging DLL on windows 7 cheaply.
I use OllyDebug.
OllyDbg
IDA is also very nice (paid)
I googled a lot but no answer found. My project is a plugin of a .Net application.
The project was started 2 years ago on WinXp 32bit platform. A 32bit COM component was used for some reasons. Because I have the source codes, I can debug into the COM component freely. Everything is fantastic at that time.
At the beginning of this year, my project is upgrading to x64 because of memory benefit. And the x64 version of the COM component is also ready. Everything works fine except debugging.
Now I can't debug into the COM dlls anymore. There is no any COM dll or interop dll listed in the Debug\Windows\Modules window. Thus, I can't specify the symbol directory for dll.
I know there is no mix mode support for debugging. So When I attach the exe, I select "Native".
I tried VS 2005, VS 2008 and VS 2010, all of them give me the same issue. Then I thought may be it is because x64. So I use the old 32 bit code which was debugged fine on WinXP to try again. But I still can't debug either.
Any idea? Is this because of the win7 platform? Or if I need to add some entries in the exe's config file?
Thanks in advance.
Perhaps, I should ask in this way:
What are the rules for the debugger to decide which module should be in the module list? If you compare the module list between ProcessExplorer and VS, you would find these two are not the same.
I have an application that allows me to scan images on my development PC which works successfully. It uses the Microsoft Windows Image Acquisition COM ActiveX dll. I am running VS2008 on Windows 7 64 bit.
I am having problems trying to deploy the Interop dll using ClickOnce. This component is referenced through the VS project in the normal way (and copy local = true). When I install the application on a Windows XP machine, I get an error saying that the library is missing (i.e. it wasn't installed / registered correctly). Having looked in the System32 directory, the dll is not there, so it has to be deployed via my app.
After looking on the web and trying various solutions, I then tried Microsoft's 'Registration-Free COM' method here: http://msdn.microsoft.com/en-us/library/ms165432%28VS.80%29.aspx
However, changing the Isolated property to True then caused 2 compilation errors due to duplicate entries in the registry. Having sorted out these entries out manually, I then deployed my app again with the supposedly isolated COM component, but when I try to scan a document I now get this message:
'The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll'
I feel like I'm going round in circles with this one. Can someone please enlighten me on how to deploy the WIA interop via ClickOnce for all versions of Windows from XP onwards?
Your help will be greatly appreciated.
Thanks
Don't copy system DLLs from your Win7 machine to the XP machine, that can't work. It would have been easier if you named the file, I would guess at wiaaut.dll, the WIA Automation provider. It probably just isn't installed on the XP machine.
Ask the client to install this download on the machine. You don't need reg-free COM, these are system components.