I am trying to debug the kernel using windbg.My host is windows 7 x64.My target is windows 7 x86 which is installed in vmware.I have successfully connected to target machine.But often I am getting an error symbols could not be loaded.I have already set the path for symbols using the url of msdn.But I unable to connect net during debugging.SO I have planned to download symbols and specify the path .If I want to download means whether I have to download the x86 symbols or x64 symbols?
You need the symbols for the OS that's being debugged, 32-bit Windows 7 in your case.
Since your target PC is 32-bit, its drivers will be 32-bit as well and will require the 32-bit symbols for debugging.
Debugging session should not matter for connectivity to internet. If that is the issue, you may want to look into that.
You may also want to check:
Have you saved your workspace settings, so that symbol path is always set appropriately?
Try !sym noisy on debugger prompt and check for which symbols its giving the problems.
Related
I'm performing dynamic analysis on a windows VM in QEMU. I would like to look up what function is currently executing inside the Guest OS based on EIP (I just want to have an idea of what the OS is doing).
Is there an equivalent of System.map for windows? When doing a similar task in Linux, that is what I would typically use.
I am aware of the windows symbol packages, but I'm trying to figure out how to do this without using two windows VMs since I don't need full debug information, just function addresses.
I am currently using windows 7
After much searching, I could find no such equivalent or software that will provide one.
So I forked an example and now generate the file that I'm looking for: https://github.com/zestrada/Dia2Dump_nm
This uses the Microsoft DIA SDK https://msdn.microsoft.com/en-us/library/x93ctkx8.aspx to parse a PDB file for the kernel, ntkrnlmp.pdb (available: https://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx)
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.
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 am developing a driver based on ddk sample "passthru" and I have trouble loading this driver in win7(x86 or x64). I have tested my driver in winxp (x86 and x64), and it works pretty well, but when I tried to load this driver into win7 (F8->Disable Driver Signature Enforcement), it seemed failed. Then, I tried the native passthru code, it also failed. I thought it failed because
I can not see any outputs using KdPrint fron windbg.
I can not see any useful information from system event.
I set a breakpoint on passthru!DriverEntry, it seems that DriverEntry has not been called.
My WDK is 7600.16385.1, and passthru is supposed to be compatible with win7. I compile passthru using command "build -cZ".
Could you help me understanding this problem, or any clue about why passthru not loaded in win7?
I have built this driver in win7 x86 checked build environment， and tested in win7 x86.
Solved: Actually, the driver has been loaded, but the output of KdPrint not shown in win7 by default, you should use KdPrintEx to specify message level, or modify registry to make debug message shown. Now I have no idea why bp failed either.
Normally you can't use a driver that was built for WinXP target on a Win7 machine. Rebuild for Win7 target.
Well your question is rather unspecific, but I see one particular problem here: Enabling test-signing and disabling kernel mode signing policy still requires you to sign the binary ... (after WHQL-tests MS would cross-sign the .cat file for the driver). Refer to this.
See:
For 64-bit versions of Windows Vista and later versions of Windows,
the kernel-mode code signing policy requires that all kernel-mode code
have a digital signature.
and:
The operating system loader and the kernel load drivers that are
signed by any certificate. The certificate validation is not required
to chain up to a trusted root certification authority. However, each
driver image file must have a digital signature.
These commands should allow to load a driver signed with anything
bcdedit.exe -set loadoptions DDISABLE_INTEGRITY_CHECKS
bcdedit.exe -set TESTSIGNING ON
You don't mention what target OS you chose when building. Icepack mentioned it. You need to actually build for Windows 7 to make it work with the new NDIS 6.0. Simply loading a driver built for XP (and older NDIS version) may not work at all.
My suggestion, use DDKBUILD.CMD and build one driver with (free build, W7):
ddkbuild.cmd -W7 fre . -cZ
and one with (free build, WXP)
ddkbuild.cmd -W7XP fre . -cZ
the above command line already takes into account the WDK you have. Note that if DDKBUILD.CMD fails to detect your installed WDK you'll have to set the environment variable W7BASE to point to the folder in which the WDK is installed (the one with install.htm, usually something like C:\WINDDK\7600.16385.1).
We are in the process of building a 64bit version of our software, but we use Flash player's OCX control to host Flash in our windows. This OCX file is a 32bit build, do you know if it's possible to host this 32bit version of Flash within our 64bit application?
It's certainly possible... Firefox has 64 bit versions that embed the 32 bit Flash player. On Linux, this is accomplished by nspluginwrapper, which is open source so perhaps you can figure out how they do it. There must be something similar for Windows.
I do not believe that loading 32-bit DLLs into 64-bit processes is supported by Windows. An OCX is a DLL with a different extension.
You need to use some kind of external (COM) host process