I am currently using a Simics module (see chapter 6) to listen for instruction fetches and data accesses, and run callbacks on all of those events so as to instrument a kernel that is running on Simics x86. For example, I can create a Simics module as follows:
/* Initialize our Simics module. */
void init_local(void)
{
const class_data_t funcs = {
.new_instance = ls_new_instance,
.class_desc = "desc",
.description = "A simics module."
};
/* Register the empty device class. */
conf_class_t *conf_class = SIM_register_class(SIM_MODULE_NAME, &funcs);
/* Register our class class as a trace consumer. */
static const trace_consume_interface_t trace_int = {
.consume = (void (*)(conf_object_t *, trace_entry_t *))my_tool_entrypoint
};
SIM_register_interface(conf_class, TRACE_CONSUME_INTERFACE, &trace_int);
}
By doing this, Simics will call my_tool_entrypoint on every instruction and every data access; allowing me to instrument the kernel I'm running as I see fit. Needless to say this is a very cool and very powerful feature.
My questions are:
Is such a feature available for programs running on a VMware ESXi (or VMware Workstation) Hypervisor? If so, where is the documentation for that feature?
If it's not available on ESXi, is it available on any other hypervisors such as Xen?
Note that I am NOT asking how to run Simics under/over VMware, Xen, Bochs, etc. I'm asking if it's possible / how to run a callback on instruction fetches and memory accesses (as I showed was possible with Simics) on another platform such as VMware, Xen, Bochs, Qemu, etc.
It sounds like you want to use "vProbes". vProbes allow you to dynamically instrument any instruction or data access in a guest OS and then callback scripts. (not sure if you have heard of "Dtrace" for Solaris, but it is similar) I have used it to trace function calls inside of the Linux scheduler for instance. The scripts have to be written in a C-like language called Emmett. This article is a good read on the technology and what is possible: https://labs.vmware.com/vmtj/vprobes-deep-observability-into-the-esxi-hypervisor
Also, here is a link to the reference guide for Workstation and Fusion. It seems a bit old, but I don't think it has changed much. (BTW, it works on ESXi as well as Workstation and Fusion)
http://www.vmware.com/pdf/ws7_f3_vprobes_reference.pdf
Related
I use remote debugging by socket connection with old v8 version. Remote debugging doesn't work with the newest v8 version. Because some methods are deprecated or removed from v8. v8-debug.h file is useless for debugging.
// Schedule a debugger break to happen when JavaScript code is run
// in the given isolate.
V8_DEPRECATED("No longer supported",
static void DebugBreak(Isolate* isolate));
// Remove scheduled debugger break in given isolate if it has not
// happened yet. V8_DEPRECATED("No longer supported",
static void CancelDebugBreak(Isolate* isolate));
// Check if a debugger break is scheduled in the given isolate.
V8_DEPRECATED("No longer supported",
static bool CheckDebugBreak(Isolate* isolate));
// This is now a no-op. V8_DEPRECATED("No longer supported",
static void SetMessageHandler(Isolate* isolate,
MessageHandler handler));
// This is now a no-op. V8_DEPRECATED("No longer supported",
static void SendCommand(Isolate* isolate,
const uint16_t* command, int length,
ClientData* client_data = NULL));
I can't find a guide to fix this issue. Is there any minimal c++ debugging example with v8-inspector?
You might want to check this sort article I wrote on the subject: https://medium.com/#hyperandroid/v8-inspector-from-an-embedder-standpoint-7f9c0472e2b7
Older debugger agent has been deprecated and removed from main codebase some time ago in favor of the inspector API, so you basically need to rewrite everything from scratch.
The tricky parts of the integration are:
websockets as trasnsport between chrome dev tools and your running codebase (in my case, an Android app with embedded v8).
appropriately handling them custom runMessageLoopInPause and quitMessageLoopInPause methods supplied in the InspectorClient.
I have created a 64-bit executable using Visual Studio 2015, intended to be run on Windows 7. The executable is a C++ wrapper that calls the main method in a Java application via JNI. The application runs as expected, but in Windows Task Manager, on the "Process" tab, my application name has been prepended with 16 hex digits. So even though my application compiles to "someapp.exe", it is listed as "80005b29594d4a91someapp.exe" in the process list when I run it. Does anyone know why this is happening, and how to make it show up as just "someapp.exe" in the Task Manager?
EDIT 1:
I should note that the hex string is always the same when it appears in the name. However, there is a small percentage of the time I run my application when it actually has the expected name of "someapp.exe". I have not been able to figure out the pattern of when the hex string is prepended and when it is not, but I estimate the hex string appears 98% of the time it is executed.
EDIT 2:
This appears to be related somehow to the use of JNI. When I remove the JNI calls, this stops occuring altogether. The following represents the entirety of the C++ code making up the "someapp" application:
#include <jni.h>
#include <Windows.h>
#define STRING_CLASS "java/lang/String"
int main(size_t const argc, char const *const argv[]) {
// Modify the DLL search path
SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32 |
LOAD_LIBRARY_SEARCH_DEFAULT_DIRS | LOAD_LIBRARY_SEARCH_USER_DIRS);
SetDllDirectoryA(R"(C:\Program Files\Java\jdk1.8.0_112\jre\bin\server)");
// Create and populate the JVM input arguments
JavaVMInitArgs vm_args;
vm_args.version = JNI_VERSION_1_8;
vm_args.ignoreUnrecognized = JNI_FALSE;
vm_args.nOptions = 2;
vm_args.options = new JavaVMOption[vm_args.nOptions];
// Set command-line options
vm_args.options[0].optionString = "-Dfile.encoding=UTF-8";
vm_args.options[1].optionString = "-Djava.class.path=someapp.jar";
// Create the JVM instance
JavaVM *jvm;
JNIEnv *env;
JNI_CreateJavaVM(&jvm, reinterpret_cast<void**>(&env), &vm_args);
// Get the main entry point of the Java application
jclass mainClass = env->FindClass("myNamespace/MainClass");
jmethodID mainMethod = env->GetStaticMethodID(
mainClass, "main", "([L" STRING_CLASS ";)V");
// Create the arguments passed to the JVM
jclass stringClass = env->FindClass(STRING_CLASS);
jobjectArray mainArgs = env->NewObjectArray(
static_cast<jsize>(argc - 1), stringClass, NULL);
for (size_t i(1); i < argc; ++i) {
env->SetObjectArrayElement(mainArgs,
static_cast<jsize>(i - 1), env->NewStringUTF(argv[i]));
}
env->CallStaticVoidMethod(mainClass, mainMethod, mainArgs);
// Free the JVM, and return
jvm->DestroyJavaVM();
delete[] vm_args.options;
return 0;
}
I have tried to remove the arguments passed to the Java main method, but that had no affect on the outcome.
EDIT 3:
Thanks to the suggestion from 1201ProgramAlarm, I realized that this was actually related to running from a dynamic ClearCase view. The "Image Path Name" column in the Task Manager was one of the following values, which directly correlates with the incorrect "Image Name" symptom that I was observing:
\view\view-name\someapp-path\someapp.exe
\view-server\views\domain\username\view-name.vws.s\00035\80005b29594d4a91someapp.exe
I would still like to know why this is happening, but since this only affects our development environment, fixing it has become low priority. For anyone else experiencing this problem, the following represents the relevant software installed in my environment:
Windows 7 Enterprise x64 SP1
Rational ClearCase Explorer 7.1.2.8
Visual Studio 2015 Update 3
Java x64 JDK 8u112
Run your application from a drive that isn't a ClearCase dynamic view.
The Image Name of the running process reference a file in a ClearCase view Storage (\\view\view-name\someapp-path\someapp.exe =>
\\view-server\views\domain\username\view-name.vws\.s\00035\80005b29594d4a91someapp.exe), the .vws meaning view storage.
See "About dynamic view storage directories":
Every view has a view storage directory. For dynamic views, this directory is used to keep track of which versions are checked out to your view and to store view-private objects
So a view storage exists both for snapshot and dynamic view.
But for dynamic view, that storage is also used to keep a local copy of the file you want to read/execute (all the other visible files are accessed through the network with MVFS: MultiVersion File System)
That is why you see \\view-server\views\domain\username\view-name.vws\.s\00035\80005b29594d4a91someapp.exe when you execute that file: you see the local copy done through MVFS by ClearCase.
Would you have used a snapshot view, you would not have seen such a complex path, since a snapshot view by its very nature does copy all files locally.
It appears as though the path is "correct" when I have not accessed the MVFS mount recently using Windows Explorer
That means the executable executed by Windows is still the correct one, while MVFS will be busy downloading that same executable from the Vob onto the inner folder of the view storage.
But once you re-execute it, that executable is already there (in the view storage), so MVFS will communicate its full path (again, in the view storage) to Windows (as seen in the Process Explorer)
I'm using CentOS 6.6 (64-bit) and RH 1.10.2
I have a waveform that requires a FRONTEND::TUNER device that is of type RX_DIGITIZER. I also have a 1.10.2 based device that is a RX_DIGITIZER_CHANNELIZER. This device has all the functionality that the waveform needs, but the waveform will not use it because of the different tuner type.
I see that it is not picked because FrontendTunerDevice<TunerStatusStructType>::allocateCapacity() (in fe_tuner_device.cpp) that my device inherits looks for an exact match on tuner_type.
I'm not seeing any elegant ways around this. Here are the two not so elegant ways I can see around it.
I can either completely override allocateCapacity and duplicate 95% of its logic, but explicitly accept both tuner types.
Or I can override allocateCapacity and modify the capabilities before passing to the superclass method. In pseudo-code:
CORBA::Boolean MyDevice::allocateCapacity(const CF::Properties & capacities)
{
if ( capacities ask for RX_DITIGIZER ) {
CF::Properties caps = capacities;
change type to RX_DITIGIZER_CHANNELIZER
return super::allocateCapacity(caps);
} else {
return super::allocateCapacity(capacities);
}
}
Is there a better way?
The FrontEnd interfaces specification as outlined in Appendix E of the REDHAWK User Manual is a guide and has been known to be interpreted in different ways by REDHAWK device developers. In your case, the simplest solution would be to change the allocation in your waveform to an RX_DIGITIZER_CHANNELIZER and connect a listener to the device, assuming the device has the ability to output wideband data (RX_DIGITIZER). Otherwise, your suggested approach is correct while keeping in mind that the device must perform the appropriate bookkeeping should a user allocated DDCs against the CHANNELIZER portion of this device.
For more information, please refer to section E.2 on Frontend Tuner Types.
How do I get the list of open file handles by process id in C#?
I'm interested in digging down and getting the file names as well.
Looking for the programmatic equivalent of what process explorer does.
Most likely this will require interop.
Considering adding a bounty on this, the implementation is nasty complicated.
Ouch this is going to be hard to do from managed code.
There is a sample on codeproject
Most of the stuff can be done in interop, but you need a driver to get the filename cause it lives in the kernel's address space. Process Explorer embeds the driver in its resources. Getting this all hooked up from C# and supporting 64bit as well as 32, is going to be a major headache.
You can also run the command line app, Handle, by Mark Rusinovich, and parse the output.
Have a look at this file :
http://vmccontroller.codeplex.com/SourceControl/changeset/view/47386#195318
And use:
DetectOpenFiles.GetOpenFilesEnumerator(processID);
Demo:
using System;
using System.Diagnostics;
namespace OpenFiles
{
class Program
{
static void Main(string[] args)
{
using (var openFiles = VmcController.Services.DetectOpenFiles.GetOpenFilesEnumerator(Process.GetCurrentProcess().Id))
{
while (openFiles.MoveNext())
{
Console.WriteLine(openFiles.Current);
}
}
Console.WriteLine();
Console.ReadKey();
}
}
}
It has dependency over assembly System.EnterpriseServices
You can P/INVOKE into the NtQuerySystemInformation function to query for all handles and then go from there. This Google groups discussion has details.
Take a look at wj32's Process Hacker version 1, which can do what you asked, and more.
Handle is great program, and the link to codeproject is good.
#Brian
The reason for the code is that handle.exe is NOT redistributable. Nor do they release their source.
It looks as if .Net will not easily do this since it appears that an embedded device drive is requried to access the information. This cannot be done in .net without an unmanged DLL. It's relatviely deep kernel code when compared to typical .net coding. I'm surprised that WMI does not expose this.
Perhaps using command line tool:
OpenedFilesView v1.50 - View opened/locked files in your system (sharing violation issues)
http://www.nirsoft.net/utils/opened_files_view.html
I'd like to get list of all Upgrade codes of all installed products on Windows box. The question is: is there a dedicated MSI function to address this request?
There is MsiEnumProducts() that enumerates all installed products and MsiEnumRelatedProducts() to enumerate all products for the given Upgrade code. But I can't find a function to get all Upgrade codes in the system.
The workaround I can imagine is use MsiEnumProducts() to get list of all installed products, open each with MsiOpenProduct() function and read "UpgradeCode" property with MsiGetProductProperty(). But this should be very slow due to multiple MsiOpenProduct() calls.
I believe MsiEnumProducts loop with MsiOpenProduct and then MsiGetProductProperty is the correct official sequence. If you really need faster and are willing to bypass the API's you could read the registry directly at HKCR\Installer\UpgradeCodes. You'll have to reverse the Darwin Descriptors though. This isn't technically supported but the reality is these keys have been there for 16 years and MSFT has been doing ZERO development on The Windows Installer. Ok, maybe they updated the version number and removed ARM support in Windows 10 LOL.
FWIW, I like to use C# not C++ but the concept is the same. The following snippet ran on my developer machine in about 2 seconds.
using System;
using Microsoft.Deployment.WindowsInstaller;
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
foreach (var productInstallation in ProductInstallation.AllProducts)
{
using(var database = new Database(productInstallation.LocalPackage, DatabaseOpenMode.ReadOnly))
{
Console.WriteLine(database.ExecutePropertyQuery("UpgradeCode"));
}
}
}
}
}
According to the DTF documentation, ProductInstallation.AllProducts uses MsiEnumProducts. The Database class constructor is using MsiOpenDatabase and ExecutePropertyQuery is a higher level call that basically abstracts doing a SELECT Value from Property WHERE Property = '%s'. So it'll be calling APIs to create, execute and fetch results from views. All these classes implement IDisposable to call the correct APIs to free resources also.
Ya... that's why I love managed code. :)