Today I broke perfmon... :(
I can start the application, the three default counters (cpu, mem, disk) are there, but the graph won't move.
The Data Source is set to "Current Activity", the "Freeze Display" button is not pressed. I just rebooted, started perfmon, and no moving graph.
I tried restoring the counters using
C:\WINDOWS\system32>lodctr.exe /R
but that did not help.
Using Windows Server 2003 R2, 32bits.
A collegue also got this problem on a similar environment, but we couldn't pinpoint the reason yet.
(For the downvoter(s): I know it's not directly programming related, but writing an app for performance without any measurements to go by with is a bit hard (but that might just be me)
To make this more interesting:
The following code also does not retrieve values:
System.Diagnostics.PerformanceCounter ctr =
new System.Diagnostics.PerformanceCounter();
ctr.CategoryName = "Processor";
ctr.CounterName = "% Processor Time";
ctr.InstanceName = "_Total";
ctr.MachineName = ".";
float val = ctr.NextValue().ToString();
// val equals 0
The image as requested:
alt text http://www.brokenwire.net/bw/file_download/23/perfmon.PNG
(So, the graph does not fill the screen, no values appear)
The accepted answer to a possibly related SO question was to call:
lodctr.exe /s:PerfStringBackup.INI
on
... a PC where perfmon works correctly
then copy the file to the affected machine, then
before a call to:
lodctr.exe /R:tPerfStringBackup.INI
It sounds like you have been working on this pretty hard. Have you checked http://www.tomshardware.com/forum/117911-45-perfmon? Then you can double check your registry to make sure it is correct. Also, if you have your windows cd, you can copy over a fresh copy of the perfmon files.
try the following microsoft solution:
http://support.microsoft.com/default.aspx?scid=kb;en-us;300956
it uses C:\WINDOWS\system32>lodctr.exe /R at the end but you are editing the registry, it might do the trick.
I hope it helps.
Have you tried repairing your Windows Installation ? Using the Windows Installation Disc ?
Right-click the graph. You said Data Source is set to Current Activity. That is on the Source tab. Go to the General tab, down to the bottom. Make sure "Sample automatically every:" is checked, and make sure the sample time is reasonable (1 is the default -- 1 second). If it's already checked, uncheck and then check it again.
Related
I've noticed an immense delay (just sitting there doing nothing) since upgrading to the latest version of windows while using tortoiseSVN to compare any file to its base version [TortoiseMerge].
I was on the fast track and got the fall creators update about a month ago and noticed this too so i reverted back and it went away. After it hit RTM I thought this was fixed but apparently I was wrong.
What do I mean with very slow?
Before fall creators update: <1 second
After: A minute or 2, as long as it takes..and that's just for comparing 1 file.
I just go read an article or something and wait for the tortoiseMerge icon to popup in the taskbar.
Repo is on my Desktop - Client is on my Laptop - same network.
Anyone with a similar experience? Did anyone find a workaround?
Edit:
The issue has more to do with TortoiseMerge than TortoiseSVN or SVN itself - I switched to Beyond Compare and it is working well for now.
The issue is already reported to Microsoft and Microsoft fixed in in Visual Studio 2017 15.6 when you recompile your code. Here the fixed MFC without the slow Get/SetPixel is used.
To fix in in Windows 10 for current and older compiled tools which use MFC, Microsoft released the Update KB4058258. The release notes don't mention the fix, but it is confirmed by the reporter that the fix is part of the cumulative update.
So installing the Update should fix it. So if you have the issue, make sure you run at least Build 16299.214 (run winver.exe to see the number).
If you have this or a higher number at last position, the issue should be gone.
The old and outdated information are archived. See the revisions of this answer for the old workarounds.
Instead of removing the "ribbon" setting, or changing security in Windows, I installed the last nightly build (1.9.9.x), and the performance is back.
I looked at the settings, and the ribbon is still checked as default. But the performance is there.
https://nightlybuilds.tortoisesvn.net/latest/x64/full/
As a workaround, you can use the TortoiseUDiff tool instead. It is still fast. Here is what I do:
Right-click a working folder in Windows Explorer and click 'SVN Commit'
Select one or more files in the 'Commit > Changes made' list
Right-click the selection and select "Show changes as unified diff"
It's not as powerful as TortoiseMerge, but if you just need to see the changes you are committing, the above method still works fast.
After installing 2018-01 Cumulative Update for Windows 10 Version 1709 for x64-based Systems (KB4058258) the speed problems for WinMerge appear to be completely fixed.
In the TortoiseSVN settings window, I
selected Diff Viewer/Merge Tool section
checked External
selected WinMerge.
Works like a charm.
It did a trick for me. I allowed TortoiseSVN program in my antivirus firewall protection settings. It made SVN Commit fastest.
Go to your antivirus. I have Quick heal. So I will tell you the steps accordingly.
1) click on "Internet & Network"
2) Click on "Firewall protection"
3) Check for "Program rules" and click on "Configure" button.
It will open a window displaying the list of allowed Exe on your system.
Your antivirus blocks tortoiseSVN and related exes, if they are not in
allowed Exe list.
4) So now click on "add" button, open dialog box will popup.
5) Go to "C:\Program Files\TortoiseSVN\bin" directory
6) Select TSVNCache.exe, TortoisePlink.exe, TortoiseProc.exe, ConnectVPN.exe And
click "open" then click OK in list window.
Here you go. Hope it helps you.
When I open Logisim on my Windows 10 device, the task bar options are all clumped together and difficult to read(Screenshot tagged in the post). But looks fine on mac.
Screenshot of Left side Task Bar
Any help would be great.
Try pressing Windows Key + Up key.
Another possible solution is to hit the Windows button. This tends to bring up the task bar in most programs, for me, at least.
This may seem off topic, but I'd create a manifest file for this particular program if it occurs only there. That may solve the problem if done correctly.
I would like to share with you this post as I wasted a lot of time to understand why the WS_EX_LAYERED flag did not work on a fresh install of Windows (my test was on a Win7, I don't know if it can be reproduced on a Win8 o.s.).
This was my code:
...
hParentWindow=hWnd;
HWND myWnd=CreateWindowEx(WS_EX_LAYERED|WS_EX_PALETTEWINDOW,_T("STATIC"),_T(""), WS_POPUP|SS_BITMAP,position.left,position.top, position.right, position.bottom,hWnd,NULL,hInst,NULL);
Then I wanted to add a transparent layer:
CWnd::FromHandle(myWnd)->SetLayeredWindowAttributes(RGB(0,0,0), 255*0.6, LWA_ALPHA);
Running the code, the window never appeared! And this was not a child window (the WS_EX_LAYERED does not work for a child window), so the WS_EX_LAYERED flag should have worked.
Why?
After spending almost a day in searching for the solution, I found that the target PC (the one that hosts the executable) had the Aero Peek theme disabled because it had never run the "Performance Information and Tools"!
So, IMHO, a programmer that is going to use the WS_EX_LAYERED in his code, must determine if the Aero Peek is turned on or not (for example by looking into the \HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM key registry and check the EnableAreoPeek registry value), otherwise some windows could not be shown correctly in any PCs.
Hope this makes you to save your time!
I have been through the same issues today (Rosario I feel your pain of 2 years ago!).
I couldn't work out why windows were disappearing completely. I'm sure others may end up at this page for the same reason.
As such I wanted to pick up on one point.
The key factor to this seems to be that "Desktop Window Manager Session Manager" service must be running for transparent layers to function.
That EnableAeroPeek registry value, which relates to whether you see a full-screen preview of the windows as you look through them (eg. with alt-TAB or hovering over task manager mini-previews), can remain off and it not connected to the availability of transparency in tests I have carried out on multiple machines.
Similarly, if that registry setting is on but the DWMSM service being off, it will not give you transparency.
Rosario I'm sorry to contradict your own answer to your own question, but I think it's an important distinction!
So far the only way to test for the availability of transparency on Windows 7 & later before making a call which fails (or turns a window invisible) seems to be by checking for a running dwm.exe process.
I've searched all over for a solution and have not been able to get them to work.
My company's product used to have the Repair option when selecting the product in the Programs and Features dialog. You could also right click on the product and select Repair there as well. Just before I inherited the installer projects, this Repair option disappeared. I looked around to see if anything was disabling this option and couldn't find anything.
In InstallShield DisableRepair is set to No. There also is no registry key set in the Uninstall section for the product for NoRepair when the product is installed. By default, I believe I should be seeing the Repair option and don't understand why it's not there. I've tried messing with ARPNOREPAIR in custom actions, all to no avail. I even created a registry key for NoRepair with both 0 and 1 for DWORD values to see if it actually would work and it did not. I'd like to say that there is some code somewhere that is disabling it, but I've checked everywhere and even talked to the previous installer coworker and he doesn't know of anything removing that option.
Does anyone have information on this?
After lots of digging around and testing I have found out some interesting things and a solution to my issue. It turns out that there was a C# custom action that was creating a separate registry entry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. Also, ARPSYSTEMCOMPONENT was being set to 1 in InstallShield which was disabling the original entry from showing in Programs and Features, while the new entry was set to show. Apparently NoModify and NoRemove work with the new entry, but not NoRepair(no idea why this is). My solution was to go back to the original entry and modify the keys that I was adding in the custom action.
We've got some in-house applications built in MFC, with OpenGL drawing routines. They all use the same code to draw on the screen and either print the screen or save it to a JPEG file. Everything's been working fine in Windows XP, and I need to find a way to make them work on Vista.
In three of our applications, everything works. In the remaining one, I can get the window border, title bar, menus, and task bar, but the interior never shows up. As I said, these applications use the exact same code to write to the screen and capture the window image, and the only difference I see that looks like it might be relevant is that the problem application uses the MFC multiple document interface, while the ones that work use the single document interface.
Either the answer isn't on the net, or I'm worse at Googling than I thought. I asked on the MSDN forums, and the only practical suggestion I got was to use GDI+ rather than GDI, and that did nothing different. I have tried different things with every part of the code that captures and prints or save, given a pointer to the window, so apparently it's a matter of the window itself. I haven't rebuilt the offending application using SDI yet, and I really don't have any other ideas.
Has anybody seen anything like this?
What I've got is four applications. They use a lot of common code, and share the actual .h and .cpp files, so I know the drawing and screen capture code is identical.
There is a WindowtoDIB() routine that takes a *pWnd, and a source rectangle and destination size. It looks like very slightly adapted Microsoft code, and I've found other functions in this file on the Microsoft website. Of my four applications, three handle this just fine, but one doesn't. The most obvious difference is that the problem one is MDI.
It looks to me like the *pWnd is the problem. I'm not a MFC guru by a long shot, and it seems to me that the problem may be that we've got one window setup in the SDIs, and more than one in the MDI. I may be passing the wrong *pWnd to the function.
In the meantime, it has started working properly on the 64-bit Vista test machine, although it still doesn't work on the 32-bit Vista machine. I have no idea why. I haven't changed anything since the last tests, and I didn't think anybody else had. (On the 32-bit version, the Print Screen key works as expected, but it does not save the screen as a JPEG.)
Your question title mentions screen capture but your actual question doesn't. Please elaborate more clearly. Is the problem that you can do screen capture of three of your applications, but not the fourth one? You can use different screen capture software that can capture OpenGL/DirectX windows. Those surfaces are handled directly by the Window Manager and won't show up with a simple 'PrtScn'.
Switching to GDI+ won't solve it, nor will switching to SDI.
If it's the content of the CView that you want, then yes, that should be right one. If it's the content of the whole screen (at least the content, without the toolbar(s) and status bar), then you should pass it the CMainFrame (that's the default name which may have been changed, the one that is derived from CMDIFrameWnd).
Can you post the code of WindowToDIB()? I've just tried it and It Works For Me (TM), but without OpenGL code in the view. Try passing the following windows to your WindowToDIB() function:
CMainFrame* mainfrm = static_cast<CMainFrame*>(::AfxGetMainWnd());
- mainfrm
- mainfrm->MDIGetActive()
- mainfrm->MDIGetActive()->GetActiveView()
and see what you get.
The contents of each window are directX surfaces and are only assembled by the window manager in the graphics card. You'd not be able to capture this unless you switch off the new interface (DWM) or code specifically for screen capture from the DWM.
Wikipedia has a good description of the Desktop Window Manager (DWM)
Sorry, I still don't understand. You're trying to get the Print Screen key to work on all four applications? Or you're trying to get the WindowtoDIB() function to work, which takes a 'screenshot' (from within your own application) of the application itself, so that it can be saved as an image file?
Also, what do you mean with 'he Print Screen key works as expected, but it does not save the screen as a JPEG.'? Print Screen only copies to the clipboard, what happens when you paste in Paint?
If your WindowtoDIB() function only 'captures' the window you pass to it, then yes, your MDI child windows are not going to show up.
We eventually solved this by creating a different OpenGL context, and drawing everything to that. We gave up on the screen capture.