I have a very strange problem. I am using Windows 7 x64 SP1. I have it installed on physical machine, as well as on the virtual machine - VMWare Workstation 9. I have downloaded Windows_Win7SP1.7601.17514.101119-1850.AMD64FRE.Symbols from Microsoft web site and they are working on virtual machine but NOT on physical machine!!! Can someone please advice me what can cause this issue, or how can I diagnose what am I missing? Thanks.
As #snoone said WinDbg was performing lazy symbols downloading dependent on what *.dll I was using (debugging). For example when I was listing x kernel32.dll it has downloaded kernel32.pdb correctly for my system. One more thing: regrading disability to download proper symbols pack - I think #Raymond Chen was correct - it was because of certain Windows Update - security updates. Thanks.
Related
It seems that it is impossible to find an image of Windows XP Professional x86 checked build. But I still need to support the software and do my work for that system. :(
Yes, I know that I can install only the checked kernel on the free build, but I still want to have a checked system, not a mix of the two.
Solutions, anyone?
UPDATE: It appears it is not clear from the question itself that what I am looking for is the installation image itself (an ISO image), so I can have the full checked build of the OS installed. NOT the service packs. NOT x64 image.
UPDATE 2: Why calling MS won't help: see http://msdn.microsoft.com/en-us/subscriptions/ff723773.aspx after "Products Unavailable due to Java-related Settlement".
UPDATE 3: See http://social.msdn.microsoft.com/Forums/en/wdk/thread/5fa40892-8207-425a-8866-0fcaebb0c343 -- someone suggests that "The only install disk of a checked XP was the release, i.e. no service packs. MSDN and Technet distributions had the disk as one of the set." Does anybody here have those disks? Seems that ours were lost in the sands of time.
UPDATE 4: Narrowed it down to a MSDN CD named "Windows® XP Professional Checked/Debug Build (English)", disc 1013, volume label X08-48914, dated October 2001. Anyone has that one?..
I bet that if you support your software to work in Windows Server 2003 then your software will also work in Windows XP, even though Microsoft's debugging symbols differ. You can install the checked build of Windows Server 2003 RTM, add the optional component for desktop experience, and it will be approximately the same as Windows XP with SP1 with some increased security. Checked build service packs are available for Windows Server 2003. So you can approximate every service pack version of Windows XP except for Windows XP RTM.
Checked versions are only available in English. You can install an MUI pack but the result is not identical to an actual Russian version of Windows. You'll have to test your software again in the actual version of Windows that your customers use, and that will not be a checked version.
These files are downloadable from MSDN:
en_windows_server_2003_enterprise_chk.iso
en_windows_server_2003_enterprise_x64_chk.iso
(The first paragraph was edited to mention that the Windows Server 2003 RTM download is also a checked build. Of course the download would be useless otherwise.)
I'm trying to install ie version 8 in a virtual box. I downloaded several files from microsoft website. One of them after start extracting the show me an language related error all the others said that the .exe file is not a valid Win32 application.
Can anyone help me how to install this??
Thanks
What operating system are you running on your VirtualBox? Because you are getting a Win32 error, I would suggest you are running a 32-bit Windows OS and have downloaded a 64-bit installer.
When downloading from Microsoft, double-check you are downloading a 32-bit installer (32-bit and x86 are essentially the same thing).
IE 8 for XP: http://www.microsoft.com/download/en/details.aspx?id=43
I have been trying to install and run a program written in vb 6.0 on windows 7. It was working fine installing and running in windows xp. The error message after installing and running it say that
Run-time error 339" : Component voice.ocx or one of its dependencies not correctly registered: a file is missing or invalid.
This program has voice recording things.
I manually register that ocx component but still error that shown like
The module "voice.ocx" failed to load.
And I try to install VB run-time and still shows the same error. I believe that Windows 7 support vb 6.0 programs.
One thing here I am not sure of is that the ocx component I have is whether 16 or 32 bit version. I don't think we cannot register 16 bit version ocx in windows 7.
And I also try to install and run in compatibility mode or even as administrator. I think it is a platform related issue? And it might be some other work-around. So, I appreciate your hints or clues on this program runnable in windows 7.
Thanks in advance.
Regards,
SEE
Just encase anyone else sees this.. here is what I did
I knew the program was running on Windows XP, with visual basic installed. I had only been given the exe and the MDB. So I created a virtual machine (stick with me) of Windows XP, installed visual basic and test the app. It was fine. Then I downloaded a dependency tool called Dependency Walker from http://www.dependencywalker.com/. I installed this in the virtual machine and asked it to open my exe.
Once this was loaded I ignored the warnings and asked it to start profiling. I ran the app, stepped through everything I could see, then exited the application. This left me with a log of the DLLs that had been accessed. Slowly I went through these checking if they existed on my windows 7 setup, when one was missing I copied it to my application directory and then from an elevated command prompt run "regsrv32 [missing_name.dll]" until there were no files which my windows 7 desktop didn't have.
the application then worked fine! This may not work all the time, because of the way third party OCX's or DLLs have been written. But it may help someone out.
Few of old Win32 components are not supported in Windows 7. There are possibilities of failure of a VB Program in Windows 7.
But there are some possible ways to fix those.
Check the following links to avail the same.
http://www.personalcomputerfixes.com/general-errors/how-to-successfully-fix-the-339-runtime-error/
http://social.msdn.microsoft.com/Forums/en-US/vbpowerpacks/thread/8cb5ab97-8407-4e49-8db6-30dcef87cbd1/
http://yang.articlesbase.com/operating-systems-articles/simple-solutions-on-how-to-fix-runtime-error-339-1830111.html
I have developed several programs with VB5 on a WinXP32 machines and then installed them on Windows 7 (32 and 64) PCs without problems.
This applications use different OCXs (16 and 32 bit version) and till now I never get problem with them. Thus I do not think that the VB5 or Vb6 could have any issue on Windows 7 machines.
On the other hand I would point out the module "voice.ocx" and investigate if it can run on a windows 7 pc, because as Katturaja sais some old ocx have problem on win7. To do that, I would create a simply VB6 project that uses voice.ocx (just an Hallo-World"), then create the installation pack and finally try to install on a clean win7 machine (for example a virtual machine). In this way you could isolate the problem.
I hope this could help you.
I am upgrading my machine to Windows 7 but I would still be supporting VS2002 (.net 1.0), VS2003 (.net 1.1) , and VB6 applications.
Is it possible to load these VS and VB6 applications, build, compile, edit code, and support this source code in Windows 7?
Best way to answer your question is to do an experiment. You can setup a VirtualBox whose guest OS is Windows 7, then put whatever programs inside and test out. If they run fine, it's okay to do the real upgrades.
Yes you can.
Refer here
http://www.vbmonster.com/Uwe/Forum.aspx/vb/33424/VB6-on-Windows-7-64-bit
You need a virtual machine. Sorry. You could always see if the virtual machine in Win7 works - but failing that, do what I did and create a virtual machine running XP and run it from there.
I'm pretty sure I've used VB6 and VS2003 on Vista in the past, so there shouldn't be a problem with 7. I'd second setting up a VirtualBox or maybe try VirtualPC to give it a go.
Even if for some strange reason you weren't able to install the development tools, you could (assuming you're using a high enough edition) use Windows XP mode for those tools that you couldn't get to run natively under Windows 7.
We are moving to an all-64-bit development environment. Unfortunately VS 2008 and, more importantly, its built-in web server, run in 32-bit mode. When debugging code that references 64-bit assemblies - Oracle.DataAccess, for example - we experience the dreaded System.BadImageFormatException.
Can anyone offer any strategies for debugging code with 64-bit dependencies in VS? I suppose we could use a 32-bit Oracle provider, but we would like to emulate the production environment as closely as possible.
I have a similar setup on 64 bit Vista where I have the web site deployed in IIS - this site has in been successfully run and debugged in both 32 and 64 bit.
The biggest problem I have found is working in a mixed environment where some members on the project team are still on 32 bit Windows (both XP and Vista).
This causes headaches with project references to Oracle.DataAccess which I have only managed to solve with bindingRedirect entries in the web.config file in order to point to the correct version of the assembly.
If you use IIS7 you can choose 32/64 bit mode. You will then have to have your projects kick up with IIS instead of cassini which takes a little bit of work, but I think it will solve the problem with Oracle at least. Honestly I don't know how that would all work when attaching at 32bit debugger to it.
We use VMware hosts to give each of our web site developers their own virtual web server. You can use full IIS (as #KevinWon suggested) and install a 64-bit version of the debugger on them. I don't know the specifics of what our guys do - I found this out over a coffee the other day.
Set up an local IIS on your computer and set it to run in 32bit mode
http://kb.parallels.com/en/2131
If you enable the Debuging mode you can work with it, just like you would with the integrated development server. But you don't have to mess with the 32/64bit assemblies