I have two questions:
I found a blog entry saying that DisablePagingExecutive should be set when using xperf:
http://blogs.msdn.com/b/pigscanfly/archive/2009/08/06/stack-walking-in-xperf.aspx
Disable Paging Executive
In order for tracing to work on 64-bit Windows you need to set the DisablePagingExecutive registry key. This tells the operating system not to page kernel mode drivers and system code to disk, which is a prerequisite for getting 64-bit call stacks using xperf, because 64-bit stack walking depends on metadata in the executable images, and in some situations the xperf stack walk code is not allowed to touch paged out pages.
Is this required to collect xperf data for a 32-bit application running on 64-bit Windows?
When collecting data with xperf for a 32-bit process on a 64-bit OS, should I be using the x86 or x64 version?
You should set DisablePagingExecutive to 1 and use the 64-bit version of WPT if you are using 64-bit Windows.
The 64-bit version of WPT is needed because the 32-bit version won't even install on 64-bit Windows.
Setting DisablePagingExecutive to 1 is needed because even a 32-bit program can make calls into the 64-bit kernel. In order to get full call stacks that include the kernel code you need to lock the metadata into non-pageable memory, which is what setting DisablePagingExecutive does.
Just set it. It doesn't cost much (it uses a bit more memory) and if you set it you don't need to worry about it.
And the simplest way to set it is to use a trace recording UI. wprui is one choice (it ships with the Windows Performance Toolkit) but I prefer UIforETW. Details at https://randomascii.wordpress.com/2015/09/24/etw-central/
According to a Microsoft blog article, it seems disabling paging executive is no longer required as of Windows 8 / 2012 to obtain complete stacks in a WPT trace.
When explaining the process for disabling paging executive, it specifically states:
Does [disabling paging executive] need to be done in Windows Server 2012 or 32-bit/64-bit
Windows 8? No.
I found this after reading another (several years old) article which stated that on starting WPR for the first time, it should prompt you to disable paging executive if it isn't already. I wasn't getting this prompt, despite the DisablePagingExecutive registry key being set to zero, so I did some digging and found the above info.
The articled is dated 2012, so those were the latest Windows releases at the time. Presumably this has carried forward in later releases (I was running WPR on Server 2016 and was not prompted).
You must use the 64Bit Version of WPT and you must set the DisablePagingExecute to 1.
Related
We have 2 machines in which we run IE selenium Test scripts. In both the machine IE 32 bit is configured. In one machine it types faster and in another machine it types each word. So in that machine i changed the IEDriver bit version as 64 and it worked as expected.
My question is, how the IE driver bit is determined as 64 or 32. Is there any relation between OS bit version ?? like if OS is 64 IE should also be 64 ?
There are technical reasons why the “bitness” of the driver must match that of the browser, mostly stemming from the fact that the driver uses Windows hook procedures for processing keystrokes by default. Those technical reasons are outlined in a blog post written by the driver author (me) some years ago. The tricky bit is knowing whether the browser is actually 32-bit or 64-bit.
You see, IE uses multiple processes when browsing, notably a broker process (which handles the outer frame of the browser), and content processes (usually one per tab, which actually renders the content). Starting with IE10, though, the challenge is that those processes (the broker and the content processes) can have different bitnesses. In fact, on 64-bit Windows, this is the default, where the broker process is 64-bit, and the content processes are 32-bit. Element interactions like sending keystrokes happen in the content process, so that’s what the driver must match.
That means the most common case is that one should use the 32-bit IE driver, even on 64-bit Windows. It must be pointed out that there are some cases where one can get a 64-bit content process (usually based on Enhanced Protected Mode), but these are a vast minority of cases.
If you use IEDriverServer.exe 32-bit execution will be faster and if you use 64-bit execution will be slower irrespective of your OS. So, use 32-bit as its faster. I have tried with both 32 and 64-bit, trust me 64-bit is way too slow.
From https://github.com/SeleniumHQ/selenium/wiki/InternetExplorerDriver#internet-explorer-driver:
The driver supports running 32-bit and 64-bit versions of the browser.
The choice of how to determine which "bit-ness" to use in launching
the browser depends on which version of the IEDriverServer.exe is
launched. If the 32-bit version of IEDriverServer.exe is launched, the
32-bit version of IE will be launched. Similarly, if the 64-bit
version of IEDriverServer.exe is launched, the 64-bit version of IE
will be launched.
AFAIK, you can run either the 32 or 64-bit driver on 64-bit Windows; I'd expect that you can only run the 32-bit driver on 32-bit Windows.
Anecdotally, the 32-bit driver is considered "faster" than its 64-bit counterpart. But--given that perceived speed is influenced by the system-under-tests's CPU/RAM--that would need to be benchmarked to be certain. That being said, I have previously used the 32-bit version on 64-bit systems because it did appear faster (especially WRT to text entry).
My virtual machine of 64-bit Debian 7.5 (wheezy) was working in VirtualBox 4.3.12r93733 on a Windows 8.1 Pro (64-bit Operating System, x64-based processor: Intel(R) Xeon(R) CPU E5-1620 v2 # 3.70GHz 3.69 GHz) machine (Dell Precision T3610) yesterday. But when I tried it this morning I got an error message saying: VT-x/AMD-V hardware acceleration is not available on your system. Your 64-bit guest will fail to detect a 64-bit CPU and will not be able to boot. I chose to continue but as promised I made it as far as choosing between system modes (regular or recovery) before the screen blacked out.
When I searched this message online I found answers saying to make sure the BIOS had virtualization enabled. My BIOS has 3 options under Virtualization Support: Virtualization, Virtualization for Direct I/O, and Trusted Execution. The first two were enabled but the last was not. (This is a work machine, so I am hesitant to load defaults without speaking to someone from IT first.)
Aside from downloading and initiating an install for Visual Studio Express 2012 (which has since been uninstalled), little has happened on this machine since the Debian virtual machine was last working. So I also investigated and uninstalled the Windows Updates from yesterday on, in case they were involved. (One in particular mentioned having to fix the BIOS.) The ones that were marked important, including the one that fixes BIOS, have been reinstalled.
At this point I started looking into VirtualBox's settings. In my online research I found several forum posts recommended going into Settings->System->Acceleration, a tab that is greyed out for me. While at Settings->System->Motherboard, I noticed my pointing device was set to USB Tablet. When I changed it to PS/2 Mouse and tried the VirtualBox again, the error message went away but the OS still does not successfully boot.
My most recent revelation happened after this: Under Settings->General->Basic, I noticed my version was set to Ubuntu (32 bit), even though I am sure it was at Debian (64 bit) yesterday. But only 32-bit OS's are options, when my machine ought to be capable of having 64-bit ones too.
My question is: What could have caused VirtualBox to lose all 64 bit options, including a working Debian (64 bit), overnight?
You probably have had Hyper-V installed and enabled.
Cross check and Disable the setting from :
Control Panel >> Programs and Features >> Turn Windows features on or off
Reference : https://forums.virtualbox.org/viewtopic.php?f=6&t=57926
try this on virtualbox:
go to your virtual machine setting (right click on VM icon > setting) then go to system > acceleration and ensure that "Enable VT-x/AMD-V" checkbox is checked.
I have my processing code in dev/processing and my Arduino code put itself in Documents/Arduino.
However, whenever I get into one environment, it changes the most recent directory for the other because Arduino is written in processing.
Is there any quick way to disconnect the two environments so that they don't use the same location for "most recent directory?" I don't know whether the mechanism is a file, a registry entry or what, but I'm on Windows 8.1
I am using both Arduino IDE as well as Processing 2.1.2 in Windows 7 environment. It doesn't change the directory.
Since you are using Windows 8.1 (which is recently released), you may face very weird problems as those softwares are not tested on those OS. You will find errors for even other softwares that are designed before Windows 8.
Is it possible to run an application on a 64 bit Weblogic 10.3.2 Server instance with a 32 bit JDK?
The reason for me to doing this is getting an exceptions while running my program using 64 bit JDK.
UCFWin32JNI.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
The error is gone when using 32 bit JDK.
If it is possible, then how?
Thanks!
A 32-bit version of a library cannot be loaded and used by a 64-bit JVM, and vice versa.
Moreover, UCFWin32JNI.dll does not appear to be a WebLogic library at all. In fact, it appears to be a library from Documentum. You ought to be looking for a 64-bit version of that library (if it is available) as it appears to be a 32-bit version going by the name and the error message produced. Finally, you'll need to place the 64-bit version in one of the directories constituting java.library.path.
No problems at all running a 32bit JVM on a 64bit platform. In fact, for some applications it can actually be more efficient, due to the fact that certain data types are innately larger on a 64bit JVM (ints I think are an example of this from memory)
A 64bit JVM provides all sorts of advantages for an application requiring access to a larger heap, but there's no harm at all in running a 32bit JVM.
Hi!
I have an old plugin (as binary, dll), used by my application. It was build for WM2003. And now it crashes the app, if loaded on Windows Mobile 6.1 (WM5 works fine, WM6 too).
The source code is not available and it's no more supported by developer. So I can't rebuild it for WM6.1.
Is it possible to patch or convert the binary to allow it to work on WM6.1 ? If so, how can I do this ?
Thank you.
Edit: I've found, that the problem is in PE loader, which acts not the same on WM6.1 (comparing with WM6 and earlier).
Does this plug-in use MFC or ATL? Earlier versions of WinMo had a different ATL/MFC version baked in, so MFC or ATL apps written in Studio will not work unless you deploy the newer ATL/MFC libraries along with the app, just as the old apps will not work on new devices unless you deploy the old MFC/ATL libraries.
This problem is rare, but some information can be found.
The common solution is to rebuild a binary in VS2008 (TCPMP new VS2008 builds for WM6.1), but this will not help, if you don't have the source code.
I've found the problem explanation and another solution in cegcc mailing list (arm-wince-cegcc on Windows Mobile 6.1). In Windows Mobile 6.1 Memory Management scheme was changes.
This slot arrangement remained pretty constant from Windows Mobile 2003 to Windows Mobile 6.0. However, with the release of Windows Mobile 6.1, things were changed to reduce the DLL pressure and to help out in the Device Manager process space.
In Windows Mobile 6.1, the stacks for the device manager are no longer allocated in the processes’ slot. Instead, the operating system uses slot 59, at the top of the Large Memory Area, for the device manager thread stacks. ...
And the workaround for this issue is to declare the DLL in registry (to tell the OS not to load it in high memory).
I don't like this workaround, so I try to find some binary patcher. And found it :)
It's not really a patcher, it's UPX - the Ultimate Packer for eXecutables. But it solves the problem perfectly. The DLL, packed with UPX don't crashes the application and runs fine.