I'm writing a project in VB6. I'm using Win7-32 bit and having problem with project, This project have writen many year's ago and now I'm recompiling that. When I issue Make xxx.exe command, VB6 starts compilation and freezes and also creates more than 10,000 *.tmp files, after minutes it closes IDE and nothing makes.
Where is my mistake?
What worked for my issue with VB6 freezing while compiling a large executable project, was to limit the CPU cores of the VB application to just one core (that is, the affinity mask set to 1 for the VB6 process).
Note that this works for me only if the VB6 process starts with affinity mask set to 1, not just by enforcing the affinity mask (in task manager) after the VB process has started.
To start VB6 with affinity mask set to 1, use the following shortcut (for 64 & 32 bit OS respectively) and start it with administrative rights:
C:\Windows\System32\cmd.exe /C start "VisualBasic6" /D "C:\Program Files (x86)\Microsoft Visual Studio\VB98" /AFFINITY 1 "C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE"
C:\Windows\System32\cmd.exe /C start "VisualBasic6" /D "C:\Program Files\Microsoft Visual Studio\VB98" /AFFINITY 1 "C:\Program Files\Microsoft Visual Studio\VB98\VB6.EXE"
In case this doesn't work, try making your project outside the VB6 IDE using the aforementioned method. For example, assuming you need to build a project named testproj.vbp in path C:\MyProjects\TestProj, use the following command (for 64 and 32 bit OS respectively) in an elevated Command Prompt:
start "VisualBasic6" /D "C:\Program Files (x86)\Microsoft Visual Studio\VB98" /AFFINITY 1 "C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" /make "C:\MyProjects\TestProj\testproj.vbp" /outdir "C:\MyProjects\TestProj"
start "VisualBasic6" /D "C:\Program Files\Microsoft Visual Studio\VB98" /AFFINITY 1 "C:\Program Files\Microsoft Visual Studio\VB98\VB6.EXE" /make "C:\MyProjects\TestProj\testproj.vbp" /outdir "C:\MyProjects\TestProj"
Unfortunately, VB6 doesn't give an indication that compilation has finished, so you need to track the VB6 process in task manager (when compilation finishes the VB6 process will just terminate).
Just for your reference, I'm running VB on a Windows Server 2012 with 2 Intel Xeon quad-core CPUs.
I've (surprisingly) had a similar issue to this before.
The best solution is to start making changes to your project settings.
Right-click your project and go to Properties. Under the "Compile" tab, go to Advanced Optimizations. Turning off "Assume No Aliasing" is probably your best bet. However, if that button is disabled, try switching from P-Code to Native Code.
If the change above didn't work, and you weren't already in P-Code, try P-Code.
Lastly, if you really want to stick to Native Code, try choosing No Optimization.
If things still don't seem to work, simply go through settings and unchecking different optimizations.
If you're still having an issue after all of that, try opening up each form and other file in your project, and see if a specific file is simply corrupt, which could lead to the sudden exit. At least this way you could trace it to a file.
If after all that fails, try compiling it on a different operating system - but I really doubt it'll get to that point.
Good luck!
I tried each of PhoeniX_2 suggestions. None of them worked. I don't know what made me try this, but the last time I compiled, I created a new exe filename than used during my previous version. Thankfully it worked. I can't understand why. It was not a permission issue or locked file issue. I thought that it might have been because a new compile overwrites the previous compile's exe file. The computer was also restarted a few times over the 2 day period of troubleshooting.
So if none of Phoenix's suggestions work for you, then try compiling a new exe filename than created with your previous compile.
Personally I had all kinds of issues with the VB6 IDE in Windows XP and later.
I keep a Virtual Machine running Windows 2000 and do any VB6 work in that.
I have few problems with it. If there is any weirdness I simply revert the VM to a baseline install.
I've found the cause for us.
We had user controls that are trying to connect to database during Initialize event. This is a really bad idea because this event runs during compiling as well as during IDE loading.
It hung for long periods trying to connect to the database that didn't exist, and then crashed the compile process so no Exe was produced (though there was no visible sign).
The solution was to do the db connection and other startup code in a public method called from the form Load event.
There doesn't seem to be any reliable way to use Initialise.
I'm using Windows 10 and got the same problem. In my case I tried to change the exe file name and for the first few times it worked. However, it got stuck again and after closing some other running applications (Visual Studio 2010, Firefox, Explorer...), restarting vb6 and compiling again, it worked again without renaming the exe file.
Related
Our previous development systems used Windows XP and Windows 7. Debugging C++ DLLs from Visual Studio worked great.
A recent move to Windows 10 has resulted in an annoying problem. We can debug once (using F5), but the 2nd time results in a linker error:
MyProg fatal error LNK1201: error writing to program database 'MyProg.pdb'
Trying to delete the .pdb manually in Explorer while Visual Studio is still open results in the error:
The action can't be completed because the file is open in devenv.exe
It doesn't matter whether you hit a breakpoint or not. Just start debugging once results in the problem. Re-starting Visual Studio resolves the issue (in the sense that you can debug once, but then you get the problem again).
If relevant:
x86 Visual Studio 2003.NET
targeting another x86 application
x64 Windows 10 Pro v1803
After hunting around for several hours some related, but unanswered, questions were found. Following suggestions in this MSDN article, along with some debugging of my own, this solution works:
Download FreePDB, a script written by MSDN user Toni76 (thanks Toni!)
Copy this script to a local folder (say C:\Apps\FreeDPB)
Download the latest version of SysInternals tool Handle (currently v4.21)
Copy handle.exe to C:\Apps\FreeDPB
NB! From the command line, run handle /? once. This is to agree the EULA. The script will not work if you skip this step!
Open Visual Studio, then Project > Properties > Build Events > Pre-Build Event
Set Command Line to C:\Apps\FreeDPB\freepdb $(ProjectName)
Set Description to Delete lock on PDB
...and now you don't need to restart Visual Studio to debug a 2nd time!
From comments, this works with multiple versions of Visual Studio on multiple versions of Windows.
Update
A more radical solution is described here which involves replacing a core Visual Studio DLL (NatDbgDE.dll). This solution only works for Visual Studio 2003 SP1, though.
In my case it was due to "Process Explorer" program, which was open alongside with my Visual Studio(I used it to check some properties of the exe I've created). After closing it problem solved.
I'd like to have a little batch script that whenever I close the visual studio GUI automatically runs subversion update, then CMAKE, and then restarts visual studio with the solution. Unfortunately I can't seem to write start the visual studio GUI and wait until it is finished.
I already tried
call "%VS100COMNTOOLS%\vsvars32.bat"
start /wait devenv solution.sln
Which starts the GUI, but the command line immediately returns without waiting.
I basically would like to have something like
call "%VS100COMNTOOLS%\vsvars32.bat"
:START
svn update
cmake
start /wait devenv solution.sln
GOTO START
Is it even possible to wait for the GUI to close?
You've run across a little trick that Microsoft uses: there are two devenvs.
One of them is devenv.com and the other one is devenv.exe. devenv.exe is the actual Visual Studio IDE that you want to run.
devenv.com, on the other hand, is a console-mode program that runs the IDE (devenv.exe) and redirects its error messages to stderr. (It's used as part of build scripts, where you want to know what happened when you tried to build.) Since it starts another program and then returns immediately, it's no good to wait on.
Due to some rules going all the way back to MS-DOS, .com files take precedence over .exe files, if you don't specify a file extension.
If you write start /wait devenv.exe solution.sln it will do what you want.
I'm creating an IE extension in C# using visual studio 2010. How do I go about debugging the extension whilst running it in Internet Explorer?
A few things are very striking:
This question is being asked a lot
Most answers, if not all, are incomplete or incorrect
So here it goes: In VS2010. perform the following:
Create your BHO project, a good starting point is: Demo IE Toolbar/BHO
Create a similar solution/project, Go to "Solution Explorer", Right Click your project or use Alt+Enter and go to "Properties":
Be sure the debug profile is selected:
We will need some post build events to register our assembly:
These are the different commands:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /u "$(TargetName)"
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /f /i "$(TargetPath)"
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" /unregister /codebase "$(TargetPath)"
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" /codebase "$(TargetPath)"
The order is important. First the assembly gets unregistered, then registered. The first time you run this, build will fail since these post-build events will fail. This is normal, the first time you build, there was no assembly registered and as such there is nothing to unregister. The second time you build, everything will work just fine. At this stage, after a successful, error-free build, manually starting IE should result in your BHO being visible:
Now we would also like to be able to just go and press F5, have the whole thing build, open IE and attach the debugger. Contrary to popular belief however, the VS 2010 debugger will not attach on its own, not even when defining "Start external program" in "Debug" (which in fact, is still necessary):
Doing so will start IE, your BHO should also run but breakpoints will not be hit.
To solve this we will use:
public virtual void SetSite(Object pUnkSite)
{
#if DEBUG
Debugger.Launch();
#endif
... Other code ...
}
This ensures that the debugger gets attached early on in the BHO lifecycle. Read about the nitty gritty details here.
Pressing F5 now will result in a few dialogs asking you which debugger to attach:
From thereon out it' s happy debugging:
I hope this helps!
EDIT
I recently was asked to bring some updates to a rather ancient BHO I wrote. Revisiting my own tutorial, I noticed some issues might come up when following it:
1) After quickly deploying a W7 machine with VS2010 (as released) I got a funky error when an attempt was made to attach the debugger:
I could resolve the issue by also installing VS2010 SP1 (as I used it originally) although I have no clue why this was happening.
2) Right now, when an attempt is made to attach the debugger, the instance of VS2010 holding my project is not in the list of available debuggers.
However, when I just cancel all dialogs and restart IE, the running instance is magically there and I can hit my breakpoints once again. The issue seems related to questions by others.
EDIT 2
The 2nd issue was solved after a full reboot, just as in the linked question.
Project + Properties, Debug tab. Select "Start external program", set it to c:\program files\internet explorer\iexplore.exe. You probably want to set the "Command line arguments" to the path of an HTML file that exercises your BHO.
Set a breakpoint on the code you want to debug. Internet Explorer will start running when you press F5. You'll see the breakpoint turning hollow, indicating that the breakpoint is not armed. As soon as IE loads your DLL, visible in the Output window, it will turn into a solid red. And the debugger automatically breaks when IE calls your code.
There is a registration step. Do always avoid using gacutil.exe, it does nothing but pollute the GAC on your machine. Always favor the "Register for COM interop" option in the IDE, the equivalent of running Regasm.exe with the /codebase option. No need for the GAC that way. Either way, VS must be running elevated to make these machine config changes, start it by right-clicking the shortcut and selecting "Run as Administrator".
Strange Visual Studio (TS 2008) problem: The IDE completely freezes whenever I switch from Release to Debug mode in a specific project. It happens right as I switch, before I try to build or do anything else.
The whole thing started out of the blue, without any abnormal change I can think of.
I tried to clean the solution, but it didn't help.
Anyone ran into this before?
If everything has worked fine and then stopped, usually it means there was some problem even though it had passed unnoticed.
Things I would try one after another:
Check which files were changed (why and how) after update from a source control engine
Review the list of extensions and plugins. Try to disable all or some of them
Close Visual Studio and kill all the development processes: devenv, mspdbsrv, vcpkgsrv, msbuild, msvsmon, vshub, vstest etc
Remove .suo, .ncb, .VC.db, .VC.VC.opendb files of the solution as well as .vs directory, which sometimes cause problems
Remove project setting files, sort of YourProjectName.vcproj.DOMAINNAME.LOGINNAME.user or YourProjectName.csproj.user. The setting file name depends on a project kind you use
Run "C:\Program Files\Microsoft Visual Studio [vs_version]\Common7\IDE\devenv.exe" /setup or "C:\Program Files (x86)\Microsoft Visual Studio [vs_version]\Common7\IDE\devenv.exe" /setup for x64 environment
In some complex cases, it helps to remove user settings, located in home %USERPROFILE%\AppData\[Local|Roaming]\Microsoft\VisualStudio[vs_version] and in registry HKCU\SOFTWARE\Microsoft\VisualStudio[vs_version]
It should reset all things to the beginning state. If it won't work, so there are additional tools to investigate. Download Process Explorer and once IDE freezes, start the Process Explorer, find the devenv process, double-click on it and go to Threads tab. Check, which thread has the biggest switch delta in case of the freeze, double-click on it and take the name (or offset) of the top function. It gives additional info where the problem may be.
Moreover, sometimes it helps to repair Visual Studio in the "Add or Remove Programs" wizard in Control Panel.
Had this problem in 2017. I ran VS 2017 as Administrator and it worked.
I've encountered this in VS 2017 (15.8). Upgrade to the newest version (15.9 at that time) resolved the issue.
VS seems to be doing a lot behind the scenes and putting project-specific files in App Data and who knows where else. I had this experience: I had a project which had two sets of identical code in two different directories: one for production, one for development. The development project started hanging on debug, the production did not. Tried all kind of settings and deleting .suo files, but no help. So I renamed the directory that the development version was in and presto, eveything worked without hanging.
In my particular case, I tried many other answers with no luck. It turned out that a call to this was hanging the debugger:
Log4NetExtensions.AssertFail("Error");
I managed to narrow it down to this line of code by bring up the threads window under [ Debug > Windows > Threads ] and clicking on the current thread to browse to the line of code it was hanging on.
When I start my process from Visual Studio, it is always created inside a job object. I would like to know how to turn this behaviour off. Any ideas?
I expect that it is created in a job object to be debugged. I want to place my program in a different job object.
It's not the hosting process. I'm talking about a Job Object. This is an unmanaged C++ application.
This happens when devenv.exe or VSLauncher.exe run in compatibility mode. The Program Compatibility Assistant (PCA) attaches a job object to the Visual Studio process, and every child process inherits it. Check if the job name (as reported by Process Explorer) starts with PCA. If so, PCA can be disabled as described in the link.
You can globally disable PCA using Run -> gpedit.msc -> Administrative Templates\Windows Components\Application Compatibility -> Turn off Program Compatibility Assistant -> Enable.
You can disable PCA for specific executables by adding a registry entry. For Windows 7, the appropriate registry key is HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant. In regedit, right-click that key, select New -> Multi-String Value, name it ExecutablesToExclude. Set the value to the full path of denenv.exe and VSLauncher.exe, on separate lines and without quotes. For me, these were:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
C:\Program Files (x86)\Common Files\microsoft shared\MSEnv\VSLauncher.exe
A related issue, on Windows 7, is that executables you build in Visual Studio and run from Explorer (not Visual Studio or the command line) may run in compatibility mode, and again get job objects wrapped around them. To prevent this, your executable needs a manifest that declares compatibility with Windows 7, using the new Application Manifest Compability section. The link gives an example of a Windows 7 compatible manifest. The default manifest provided by Visual Studio 2010 does not include this Compatibility section.
I'm not aware of any ways to control this aspect of processes spawned for debugging by VS.NET. But there's a workaround, which is applicable to any situation in which VS.NET can't or doesn't start your process in the exact way you want:
Start your process (possibly using a wrapper EXE that runs as part of the post-build event), then attach to the newly started process using Tools/Attach to Process. If you break into the debugger as part of your startup code, this won't even be required (and you can also debug startup issues...).
I can't reproduce what you're seeing. I've created an unmanaged C++ application in both VS 2005 and VS 2008 and I have no problems associating that process to a new job object when starting the process in VS.
Are you sure the debugger is doing this?