I have a machine with Windows 8.1 and the ADK (xperf 6.3.9600) installed.
I have another machine with Windows 7 SP1 and the 8.1 ADK (xperf 6.3.9600) installed.
If I use xperf to generate a trace on the 8.1 machine, I cannot load that trace on the Win7 machine; it gives me the error The file or directory is corrupted and unreadable. (0x80070570).
The ETL file can successfully be loaded on the machine that generated it and on another machine that is also running Windows 8.1.
Is it only possible to load trace files on an equal or higher OS than the one that generated them? Why doesn't it just require the same xperf/WPA version? Or does this work for other people and there's something I've overlooked?
The error message means the trace is corrupted (ERROR_METADATA_MISSING). Microsoft told me it can happen when you use a 32Bit WPT instead of a 64Bit WPT on a 64Bit Windows.
A normal ETL trace opens fine under Windows 7:
I routinely load traces from other machines and analyze them. I am running Windows 7 SP1 64-bit and I can analyze traces from Windows 8.1, and any other post-XP version of Windows.
You are probably not recording the traces correctly -- perhaps you are missing the merge step? I recommend using UIforETW, as discussed here:
https://randomascii.wordpress.com/2015/09/01/xperf-basics-recording-a-trace-the-ultimate-easy-way/
If it doesn't work then it's a bug, but it should work.
I assume that you are running 64-bit Windows. Some traces take a lot of memory to load so I recommend that you be using a 64-bit OS.
It could also happen if you compress the trace when recording it on Windows 8+, because Windows 7 doesn't support loading compressed ETW traces. However that's not something you would do accidentally -- you need to add the -compress option when doing "xperf -merge". However, if you switch to using UIforETW then you do have to be aware of this. UIforETW defaults to compressing traces and this has to be disabled if you want to view them on Windows 7.
Related
Here is the situation:
App: C# Platform: X86
DLL: C++ Platform: WIN32
Test1:
(Rugged Tablet PC) with: Windows Embedded 8 Pro
32-bit Operating System, x64-based processor
The app runs fine, but the call to the DLL crash.
Test2:
(Rugged Tablet PC) with: Windows 8 Pro
32-bit Operating System, x86-based processor
All OK! App and call to DLL are fine.
Thank you for helping me to figure what is going on. What is it crashing in Test1?
Thanks.
Windows 8 Embedded is customized to not include all the features that the full version has. This means less stuff running in the background, and less files that may need security updates.
But it also means if you try to use those features you will fail. The exception message should give you information about what was missing. I suggest that you log the exception information, to help you troubleshoot or work around the issue.
The included set of features is fully customizable, so you will need to contact whoever you got the tablet from in order to determine everything that is missing.
I currently have a 32-bit PowerBuilder application that we are trying to port over to a Windows 7 64-bit environment. Realizing the obvious that PowerBuilder 10.5 was built previously before Window7 came out and the big also the obvious fact that this application was built within a Windows XP 32-bit environment.
The 32-bit PowerBuilder application spits out the following error message when deployed on a Windows 7 64-bit machine.
Application Terminated. Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow
The database profile setup points to an OLEDB and the backend database is MSSQL 2008. Currently the application does run on the Windows7 64-bit environment and seems to be working in an inquiry mode only. Meaning we can read some of the records on the datawindow, but as soon as you try to make a transaction it blows up.
My question is - Is it possible to get a 32-bit app working in a 64-bit environment?
So far the client is asking to come up with possible solutions without the idea of upgrading to PowerBuilder 12.5. Essentially they want to stay at 10.5 but yet get the app working from a 32-bit environment to a 64-bit...apples to oranges if you know what I mean. Further investigation is needed into whether the code will not function in 64bit or dll issues with powerbuilder client runtime in 64bit. They are really trying to stay away from any app rewrite since the application is older than when Christ was a carpenter. The app was originally built in PB 6.5 I think.
So far I have the following ideas but I am new to this:
- I understand that Windows 7 comes with a virtual machine IIRC. I think it's called WOW64. Is it possible to create a virtual on a server and have the users run a 32-bit application inside a 64-bit machine? Then create a shortcut of somekind for the user to simply click on?
We do have a virtual XP machine and a virtual Windows7 64 bit machine for testing. PowerBuilder 10.5 actually installed on Windows 7 and seems to be working fine. However running the application in run mode or debug causes many errors as you can imagine.
The application has been built in XP and run on Windows 7, but the results yeild the above error message.
I have not looked yet into the Run under Compatibility mode, but I am told by the team it will not work.
I have not looked at UAC or ALC User management yet. Could that be something affecting the 64-bit system?
I know this is app unrelated but...I have seen in some cases 32-bit applications work in a windows 64-bit environment by simply targeting certain DLL files. An example case is Microsoft Flight Simulator X where the 32-bit game would crash in windows 7 64-bit. The solution for that was to simply go get a Vista 64-bit DLL file called uiautomationcore.dll and copy that into the windows environment. The Games also have to be installed on the root of C: in order to work.
Does anyone have any recommendations on how I can approach this problem?
I apologize If I'm vague in my notes here.
UPDATE: Has anyone had any experience with PB 10.5 runtime files on a 64 bit machine? I am wondering if the powerbuilder client runtime is installing its dlls into the correct location of the application C:\XXX or can't find it? Wondering how to approach this.
Basically nothing should prevent a 10.5 PB app to run on Win7/64. I develop and run several products in PB11.5 (also a 32bit IDE) on a win7/64. And btw, some older PB like 9 still run on Win7, so is likely PB6.5. The problem must be elsewhere, relative to the app design.
WoW64 (and Wow6432Node in the registry) is not a true VM, it's a bunch of services and system API hooked with fallbacks for 32 bit applications (and legacy applications that do not conform to the novelties introduced since Vista)
Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow sounds typically like an incorrectly handled return value (where a computed row number is getting negative or null before trying to access a property or data at that given invalid row), or it could be relative to the way to get back an autoincrement value from the db after an insert
beware of the UAC management that could lead to unexpected behavior with legacy application, especially if the application is using a database: the UAC guidelines tells not to install data managed by the application in the Program Files folder that is now Read only (since Vista - that guideline is since XP). Instead you must put that into a ProgramData sub-directory if it is accessible by everyone and into a user local AppData if the data is just for the current user. Win7/Vista can silently conforms to the standard by duplicating the data locally to the user (in the Users\username\AppData\Local\VirtualStore) while still pretending to the application that it is currently accessing it from Program Files...
you could give a try with Dependency Walker to look for the incorrect dll problems
We moved many of our applications to Windows 7 64bit. The only issue we ran into was with the database connections. You are running a 32bit application so you need to connect to 32bit database. If you bring up "Data Sources (ODBC)" from the control panel, you will be looking at the 64 bit entries. You need to use the 32 bit ODBC found in "C:\Windows\SysWOW64\odbcad32.exe". The Registry entries you need are in the following locations...
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
or
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
I've got a driver for a custom PCI card, which builds and runs fine on XP. I'm trying to use this custom hardware on W7, and am trying to build and run my driver.
I've got the latest DDK from Microsoft, and build my driver for XP using Windows XP "x86 Free Build Environment". Everything installs & works fine. (Build using a DDK "build" command)
If I use the Windows 7 "x86 Free Build Environment" build environment, everything builds fine. I run it through the PREfast and staticdv code checkers, no errors from either. ( I get a couple of warnings about "The dispatch function 'FooFnc' does not have any __drv_dispatchType annotations" - are these likely to be the issue? )
When I install, the install starts OK (standard error about drivers not being signed), but gets to a certain point and then hangs, then fails with a timeout error. The device then shows up in device manager as installed. At this point the PC won't shutdown or boot, but hangs indefinitely. I'm forced to boot into Safe Mode and uninstall the driver from there.
So my question(s) are:
If there has been a change in the driver model between XP and W7, what's the best way to find it? I can't see anything on MSDN.
How would I go about debugging the driver? The box doesn't start, so it's not like I can run up WinDBG.
Any specific W7 driver gotchas that are hidden away?
I've tried to keep this as generic as possible, but if more detail would be helpful I'll provide more
AFAIK, the biggest changes have been made in video and network drivers. Other drivers retain backward compatibility and can be run on W7 even with no recompiling.
Run your driver under driver verifier and turn on generating crash dumps with a keyboard (very helpful in case of system hangs, you can manually generate crashdump, analyze it and find what was wrong).
Hope this helps!
How can I trace a system responsiveness and application resource usage issue on a remote computer? I deployed my application(written using unmanaged c++ code) on my client's computer running Windows XP sp3 pro, but its running very slowly and I want to diagnose it since it runs well on my Windows 7 machine. How can i fo it remotely and if thats too difficult how can i do it onsite?
You need to find the bottleneck.
Usually it is either a CPU, disk or memory bottleneck. You can find out this by using perfmon or sysinternals tools such as filemon,diskmon, procmon ... These can be left running to gather and store data, although there could be some performance implications.
After you find the bottleneck, you need to see if it is due to anything you are doing or just the machine does not have enough resources ...
There are some profiling tools as well which come with VS and you can use to isolate the problem.
You can't use XPerf against Windows XP, sorry :(
I have installed Xperf performance analyzer from Windows SDK and captured a trace as described in the documentation using following command:
xperf -on SysProf -stackwalk profile
Still, the stack trace does not contain any callstack data.
My platform is Vista 64b. Are there any special settings or tricks needed to capture callstacks on 64b Windows?
After some more searching I have found one setting:
Set registry value DisablePagingExecutive = 1 and reboot (see Windows Performance Toolkit FAQ).
While this sounds great, it does not seem to help at my system, still no call-stacks.
After contacting Microsoft support their reply was with x64 Vista you can capture only callstacks of x64 native applications, not 32b ones.
Windows 7 seems to have removed the limitation and it works fine on Win 7 x64, at least this says Valve presentation on Xperf.