I am using Microsoft Visual Studio 2008 for development for Motorola WR41N0, which has Windows CE 7.0 operating system. As program was initially used on Windows CE 5.0, I just changed settings to fit to new operating system. Everything is going ok, except debugging. I am able to set breakpoint and it stops on it, but I am unable to make steps (F10 key). I made a build for older device Motorola WT4090 with Windows CE 5.0 and it was running ok and I was also able to debug in steps. Then I switched devices and it deployed older version on new device. Its graphical interface didn't start, but I was able to debug start routine in steps. After rebuild and redeploy I wasn't able to debug in steps again. Please give me some advice what to do, thank you.
If you are developing using C/C++ you may need to install those patches on your VS machine:
http://www.microsoft.com/en-us/download/details.aspx?id=11935
http://support.microsoft.com/kb/2483802
(should be the same fix, but it's not easy to understand this on MSDN...)
Related
I am currently trying to build a simple Win 7 x64 USB driver using this guide: https://msdn.microsoft.com/en-us/library/windows/hardware/hh706187(v=vs.85).aspx
Host is using VS2013 & WDK 8.1
Because I don't have a null-modem cable (or any other means of setting up a debugger connection between host and target), I just filled my settings with the default ones found here, expecting some sort of error to return, but the configuration process went through without a hitch, displaying
WDK Remote User Account successfully created
Installing .NET Framework 9possible reboot)
Installing VC Redist (x64)
Installing test automation (x86)
Installing test automation (x64)
Installing debuggers (x86)
Installing debuggers (x64)
Installing driver test framewok
Registering logging components
Configure debugger settings (x64) (possible reboot)
Configure computer settings (x64) (possible reboot)
Creating system restore point
Complete
So I assumed that what I assumed about serial/com ports to be wrong and continued to attach the WKM Debugger to 'Kernel' of my target computer, which was listed under the "Available Processes" datagrid. When I click the 'Attach' button, however, I get an error that says:
Windows Debugging Extension for Visual Studio
Could not start debug session, error 80070002: The system cannot find the file specified
I've tried Building/Rebuilding the project many times, and Provisioning the target computer also multiple times to the same results. I saw that question number 25776839 also had the same issue as me, but he mentioned something about changing VS's default from Kernel Debugger to Remote Debugger, which I'm not sure how that can be accomplished, but also caused other problems. I've also tried to "attach process" using the same setting via WinDBG but did not produce anything useful.
Also, I switched from MSVS2015 and WDK10 to MSVS2013 and WDK8.1 because their tutorial files led me to missing header files (warning.h many others), and package files.
Can anyone show me what I did wrong or what I need to do to fix the 80070002 error? Yes, I am new to driver dev.
I'm working on an AIR app that uses a Native Extension for windows that I developed for the same project. The app calls an ANE method called pingFunction and passes it a String containing the IP address where the pingFunction will perform, believe it or not, a ping test.
The application and it's ANE work great on Flash Builder and even after making it a release, they keep working like a charm on the development PC. The problem is that I've tried on two other computers and the application is throwing the following error:
ArgumentError: Error #3500: The extension context does not have a method with the name pingFunction.
at flash.external::ExtensionContext/_call()
at flash.external::ExtensionContext/call()
at com.mycompanyname.myappname::MyAppName/sendPing()[...
At the beggining I thought I had to do with the fact that I was using a DLL I compiled using the Debug configuration on Visual Studio instead of the Release configuration, because I read that sometimes the a debug-version of a DLL can use external DLLs. So, I changed it and rebuilt the whole library as a release build. Sadly for me, I'm still experiencing the same result.
Also, I tried changing the swf-version of both the AIR app and the ANE to the AIR SDK version I'm using (14.0), and got again the same error.
The development computer is running Windows 8.1 and the others, where the app is not working, Windows 7 and Windows 7 Service Pack 1.
Any ideas about why this is happening? Any questions or comments that might lead me to the right track will be deeply appreciated.
Error#3500 is coming because you don't have the required runtime installed on those machines, which is necessary to execute any c++ code .
On your development machine you have visual studio installed and hence you also have msvcr.
Solution of the problem is:
Install msvcr i.e. Microsoft Visual c++ redistribution - 2012 from here.
you need msvcr anywhere you want to run any VS compiled c++ code.
Greeting all,
I am at a point deciding which bit version to go for and am keen to hear your advice on this.
We have been running our build automation on a Windows 2003 32bit server with NAnt and CruiseControl.NET, and others including Visual Studio and relevant toolsets. As we are now looking into building for web applications which require IIS7, I consider to set up a new build environment in Windows Server 2008 R2 64bit.
However when I test run build automation on my Windows 7 64bit machine, I bum in many glitches relating %programfile%, e.g. checked out projects look for MS SDKs\Bootstrapper\Engine under the wrong %programfile%. I googled for solution and some of them require changes to project file - which I am not sure if appropriate as it likely affects how other developers build project on their dev environment.
So now I am thinking maybe I should have Windows Server 2008 32bits instead as I am not sure how many more of these compatibility issues I'd bum in - they can be quite a time waster. Is my suspicion on this correct? Should I stay with 32bit to be safe/ for a easier setup? Would it be sustainable having a 32bit CI server?
Much appreciated if you can comment on this and let me know your experience regarding an OS upgrade on a CI server.
Ok. So after days of effort on this I've decided to re-configure CI on a 32 bit machine due to this showstopper I've bumped in.
1. (Showstopper) cannot build silverlight project running msbuild.
I receive the following error when msbuilding a csproj:
C:\Program Files
(x86)\MSBuild\Microsoft\Silverlight\v3.0\Microsoft.Silverlight.Common.targets(101,9):
error : The Silverlight 3 SDK is not installed.
[SilverlightApplication1.csproj]
Though the recommended solution is to use the 32-bit MSBuild and target x86 or AnyCPU platforms to build your Silverlight projects according to http://blogs.msdn.com/b/visualstudio/archive/2010/05/07/building-on-cross-targeting-scenarios-and-64-bit-msbuild.aspx, I cannot get it working by loading 32bit msbuild from C:\Windows\Microsoft.NET\Framework\v4.0.30319 and set in NAnt:
<msbuild project="${SilverlightApplication1.csproj}">
<property name="PlatformTarget" value="x86"/>
</msbuild>
I've written a quick C++ console app using VS2010. I'd like to run it via the remote debugger on the Windows Server 2008 platform, in order to determine why I can't enumerate the CLSID_AudioInputDeviceCategory on that OS.
The console app works on the XP and W7 platforms.
The remote debugger gives the following error when I first tried to run the console app:
The program can't start because MSVCP100D.dll is missing from your computer. Try reinstalling the program to fix the problem.
I did try just copying this DLL from my development machine to the target folder on the remote machine, but it returned an even more obscure message:
The application was unable to start correctly (0xc0000007b). Click OK to close the application.
I've tried installing the VS2010 C++ re-distributable on the target host. This has no effect. I'm out of ideas, does anyone have any suggestions?
Having spent some time on this problem, I've noticed that the Windows Audio service on server 2008 was disabled, but my query is more to do with getting remote debugging working on the server 2008 platform than solving my audio hardware enumeration problem.
Thanks to Errata, I had a look at
Project Properties -> Configuration Properties -> C++ -> Code Generation
I changed Runtime Library from Multi-threaded Debug DLL to Multi-threaded Debug (/MTd).
This allows remote debugging without having to rely on the correct debug DLLs residing on the remote machine.
I hope this helps someone out there!
I had this exact situation. I grabbed copies of MSVCP100D.dll and MSVCR100D.dll. However I grabbed them from system32 (the 32-bit version), which resulted in the 0xc0000007b error.
0xc0000007b apparently means invalid DLL, often architecture mismatch between program and DLL (i.e. x86 and x64). In my case I grabbed the wrong (32-bit) version of the DLL from my developement computer resulting in 0xc0000007b. After grabbing the file from SysWOW64, it worked.
I'm developing an application in 3D in a win 7 64bits machine, in visual C++ 2008. All runs correctly. When I check this application in a clean machine in a VMWare virtual machine with XP 32bits (hardware 3D activated) or in a machine of a friend of mine, the application fails.
The behavior of the application is different (into the clean machine) depending of the compilation (debug or release) and if I compile with MD(d) or MT(d)
My question: it is possible to debug the application into the clean machine? Exists a central log like /var/log/message but in windows? How to check what dll are in use in my dev machine, in order to compare with the installed in the clean machine?
Thanks!!
If its on the same network you can you the remote debugger ! But you may first want to check if its not a 64bit app on a 32bit OS.
Make sure the bitness is correct and that the correct VC++ distributable is installed on the test machines.
If that doesn't help, then try this for fast debugging:
Grab the debugging toolkit from MS (http://www.microsoft.com/whdc/devtools/debugging/default.mspx)
Install it on your development machine.
Copy the installation folder to the machine you want to debug on.
Copy / Install your program to the machine, remember the *.PDB files.
Start WinDBG from the debugger folder and use the 'File->Open executable' command to start your app. WinDGB will break fast and you can debug from there.
If you want break points and such, look up the commands in the WinDBG help files.
You could try running your app under dependency walker (www.dependencywalker.com). If the problem is missing or incorrect dlls, dependency walker will show it up very quickly.
On XP you can use the built-in debugger, ntsd.exe. it's basically like windbg lite and requires no additional install.