today I found that my laptop's fan is worked in full level. after checking performance tab in task manager I see CPU usage is 100% and not change. I see webproxy.exe process in top of resource monitor list and everytime I end this process, after 1 second it run again.
I searched for it but can't find any help. I just suspend it for help my dear CPU.
OS : windows 7 Professional
Arch. : x64
create a zip code, name it webproxy.exe, replace it with the real webproxy.exe file in C:/windows/syswow64 folder or where ever that is, in the safe mode.
I faced the same problem since I installed the "Web Freer".
It also copied the "webproxy.exe" file in the "C:\Windows\SysWOW64" location and even when I uninstalled the program, it ran it from there, so you may need to delete it by yourself from there too. It may help preventing the same problem again.
Related
I hope the question is not too vague and someone can add some light to my problem.
I created a Windows application (makefile) with the chromium project (already asked about this problem in the chromium forum) and Visual Studio 2019.
The application starts some processes and each of them used around 20 KB memory but strangely this same application uses over 200 KB per process is some PCs with same Windows version.
(Memory usage after starting the application, nothing else done)
I have been fighting a couple of days with the compiler/linker options with no success. Still huge memory usage.
Chromium examples did not show this problem using my makefile which made me even more crazy.
At the end I ended up changing the name of the exe file, instead of app.exe just app1.exe and...problem gone, normal memory usage in all PCs which shown this problem.
I changed the name in the makefile to generate same executable but with different name and also changed in Windows Explorer the name of the original and problematic exe file with same positive result.
I renamed in Windows Explorer the good app1.exe application back to app.exe and the problem appeared again...
I am searching now for some kind of Windows configuration or program which could generate this problem but no luck so far. Windows Firewall already disabled.
or could this be some kind of virus?
Problem solved...thanks to ProcessHacker tool I found out that the library "verifier.dll" was loaded in the bad case.
This dll is part of the Windows Application Verifier tool. I do not remember to have used this tool before, it is even not activated.
I then found out that there is a registry entry:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\
where I could find the name of my application. After renaming this entry everything works as expected.
I will now investigate what the variables inside this entry mean:
GlobalFlag = 0x02000000 and PageHeapFlags = 0x2
I am using foxpro apps under Windows 7. During the compilation one of my program it suddenly became freezing until I move the mouse or press any key. And this happens all the time while I am working with prog.
This happens when I move only the data to a mapped directory on the host. If my application, foxpro and the data are in the same directory on the virtual machine there are no problem with it.
This happens when my data is not on the virtual machine.
Can it be a caching issue?
Change the registry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW]
Save export as backup. Then change value "DefaultSeparateVDM" to "yes"
If you have 64bit then you need to create a file for 16bit applications that use the internal start command in separate memory space as follows:
Start /separate command
Also have a look at this article. http://www.reddit.com/r/Database/comments/2kz0x5/dbf_file_getting_corrupt/
There kind of similar problem, who knows, maybe it would be helpful for you
I have run into similar in the past, and it doesn't have to do with VFP application and data residing in the same folder. What has happened to me is the debugger. You mention "...while I am working with the prog." tells me you are in the VFP development mode, and not run-time from the app itself. If you have issues where your debugger has breakpoints, or other flags that have become corrupted somehow, I have done
CLEAR DEBUGGER
But that is something going back several years and MIGHT be what you are encountering.
Have you ever experienced a slow linking process in a C++ project compile (I'm using VS2013)? I get linking process taking 15 minutes after a 5 minutes Build. A Rebuild or Visual Studio restart does not fix the issue.
Task manager shows mspdbsrv.exe taking a full core (25% on a 4-core), and pdb file creation is very slow, Kb after Kb it reaches 50 Mb.
Additional info:
the same project on another computer build and link in acceptable time.
antivirus is disabled
I've tried changing the pdb file creation location: no success
I've set the linker output Verbose, but it stops at one debug row and then wait all the time there.
VS2013 is updated to SP4
Hard disk activity led on my laptop is mostly turned off, so there's no full activity on the disk.
I'm running Windows 7 Pro.
VS2013 is run with administrator rights
Thank you.
Fixed changing "Debug Information Format" from /ZI (Edit and Continue feature) to /Zi. I still have no clue why this cause a slow linking only on a specific computer and not for the others. Hope this could help people coming here for the same issue.
Is it using Link-Time Code Generation? On VS2010 that step was single threaded so it takes much longer than the apparent compile step. On later versions this step was improved to be multithreaded, according to blog posts. It also mentioned that PDB access is a bottleneck. So, maybe you have an old mspdbsrv.exe on that system? Look at the version info on the file, compared across machines. There might also be some option to control its locking and multi-use behavior, hidden away someplace.
I get the Microsoft VS Delay Notification pop up consistently when I am trying to attach the debugger to a remote process (Native only, with no authentication). The process runs as a service on the remote machine, but Visual Studio (2005) seems to have no problem with that when it's running as a service locally.
I've loaded the symbols correctly (as in specified the right directory under Tools\Options\Debugging\Symbols), but this doesn't seem to help.
I've tried starting VS 2005 in Safe Mode, but that doesn't seem to make a difference either.
I had the same issue and used ProcMon util to look at waht my devenv were doing.
In my case it was waiting for loading symbols. So you you should check your Env. variable _NT_SYMBOL_PATH and if there is cached symbols if no - all this time your VS is waiting for downloading it.
One possible solution is you have many currently set or lingering (invalid) breakpoints.
Try clearing all the breakpoints and see if it helps.
There are more possible solutions here:
http://connect.microsoft.com/VisualStudio/feedback/details/498240/microsoft-visual-studio-is-waiting-for-an-internal-operation-to-complete
Hope this helps.
I've just had this problem when I turned on both native and managed debugging on a single application.
Turning off the native debugging fixed the problem.
The one thing that helped me is updating the package. Open the solution that is having this "waiting for internal operation to complete" then Go to Tools - Nuget Package Manager - Package Manager Console. Then run "Update-Package". After the update, I was able to close and open the solution with no problems. Hope this helps your issues.
I had the similar problem and it occurs because of the variable expression I created.
For example:
variable1 = variable1 - variable2 (gets warning)
variable1 = variable2 - variable3 (No Issues)
I had the same problem, did a lot of googling tried several things but didnt solve the problem. Finally I used processexplorer to check the devenv process and found there is a child process for devenv.exe, it was cmd.exe and it has another child process node.exe. So I went to Programs and Features and uninstalled Node 1.1 VS 2013 extension and Node package manager. It took quite some time to uninstall it even though I am using i7 quadcore processor with 16 GB RAM it took almost close to 1 hour to uninstall these two sofwares from my laptop. And this solved the issue.
How can I find what's hanging all new installations on a Windows box?
While testing an installation script on Windows (XP Pro, if it matters) I've run into a situation wherein any and all attempts to install anything on the system hang waiting on who knows what. When the system is restarted, all queued up attempts at installation then go through their exit paths with pop-ups that report the installation is being aborted due to system shutdown having been requested. Of course, reboots do not cure the problem. The system otherwise runs fine.
So... How can I determine what part of the OS I've wedged? (Something in the registry, I suppose, but I'm a real greenhorn when it comes to Windows.) Most likely, something from a preceding install attempt went awry and is now blocking even though I saw no errors reported. Once I figure this out, I want to put in a check for this sort of thing, possibly at both ends of my install scripts, if that seems reasonable.
Thanks for your input.
UPDATE:
Unfortunately for me, rebuilding from scratch to get to the point the system's in now is about 9 hours. I'd like to unwedge it from where it is now rather than reload (again). Procmon seems great but I haven't got SP2 installed, only SP1! -frown- So, other ideas are welcome.
I assume you've tried logging the install to see where things go wrong?
Try rolling back to before things went wrong using "System Restore", if that doesn't solve it and the MSI log files show nothing useful then I'd take the plunge and reload before wasting any more time on it.
That said, if you're developing installers then taking an image of this PC in it's crappy state could be a worthwhile exercise. Some point in the future when you have more time to debug you can try and figure out what the problem is.
P.S. I'm assuming you're asking this question from the point of view of someone developing an installer and not as a tech-support question... otherwise this question should probably be closed as not-programming-related ;)
Try using Procmon to figure out where the installer is having problems, if you set a filter it will report all file and registry activity for that process.