I am using DiUninstallDriver for uninstalling a driver.
The syntax is:
BOOL DiUninstallDriverW(
HWND hwndParent,
LPCWSTR InfPath,
DWORD Flags,
PBOOL NeedReboot
);
The NeedRebbot parameter is explained:
A pointer to a value of type BOOL that DiUninstallDriver sets to indicate whether a system restart is required to complete the uninstallation.
But in my case, the returned value is False (=Reboot is not needed), but in setupapi.dev.log I see that reboot IS required!!
! dvi: Query-removal during install of 'PCI\VEN_8086&DEV_XXXX&SUBSYS_YYYYYYYY&REV_11\1&11111111&1&B0' was vetoed by 'PCI\VEN_8086&DEV_XXXX&SUBSYS_YYYYYYYY&REV_11\1&11111111&1&B0???' (veto type 5: PNP_VetoOutstandingOpen).
! dvi: Device required reboot: Query remove failed (install) 0x17: CR_REMOVE_VETOED.
I am OK with the reboot that is required (maybe a handle to this driver is opened), by why the API returns false and i have no indication that reboot is required??
Related
I'm trying to run an application on Renode that uses ADC and DMA for the STM32F030F4P, I created a stm32f0.repl file with the dma and adc as follows:
dma: DMA.STM32LDMA # sysbus 0x40020000
[0] -> nvic#[9]
adc: Analog.STM32F0_ADC # sysbus 0x40012400
referenceVoltage: 3.3
externalEventFrequency: 1000
-> nvic#12
dmaChannel: 1
dmaPeripheral: dma
When I run Renode, I get the following error:
For parameter 'dmaPeripheral' of type 'Antmicro.Renode.Peripherals.DMA.IDMA' found attribute at C:\Program Files\Renode\platforms\cpus\stm32f0.repl:151:5 with value [ReferenceValue: dma]
Parameter is not assignable from the reference value, constructor rejected.
At C:\Program Files\Renode\platforms\cpus\stm32f0.repl:146:6:
adc: Analog.STM32F0_ADC # sysbus 0x40012400
^
What is the correct value for dmaPeripheral?
As it's optional, you can remove it completely. This would lead to DMA not being used.
It seems that what you have written should be doable, and it's a bug that it's not possible. The STM32LDMA should implement the IDMA interface and it doesn't.
I would suggest filing a bug on Renode's GitHub
Disclaimer: I'm one of Renode developers
My Anchor program is giving me a Transaction simulation failed: Error processing Instruction 1: custom program error: 0xa7 with nothing useful in the logs.
How do I even begin to debug this?
Custom Program Error 0xa7 is Error: 167: The given account is not owned by the executing program.
This might happen if you pass in an account that's expected to be owned by a program, but isn't.
This can happen accidentally if you forget to set declare_id!(/* ... */) to the program id you're trying to hit.
Consider logging the program id that you're using in your javascript client:
console.log(program.programId)
And then seeing if that matches the public key that's in your target/idl/yourprogram.json file.
I compiled inno-setup with XE6 myself. (I know, the document suggested older delphi versions, but I only have new IDE)
I want to use pascal script to customize setup. But even I added a simplest [Code] section, the created installation crash.
[Code]
function InitializeSetup(): Boolean;
begin
end;
The created setup.exe failed while being installed:
[22:10:29.945] *** Setup started
[22:10:36.182] Setup version: Inno Setup version 5.5.4 (u)
[22:10:36.186] Original Setup EXE: D:\Classics\Save\Installer\Win_Platform\Inno Setup\test\Output\setup.exe
[22:10:36.190] Setup command line: /SL5="$911152,176640,176640,D:\Classics\Save\Installer\Win_Platform\Inno Setup\test\Output\setup.exe" /SPAWNWND=$7B05B8 /NOTIFYWND=$1150B10 /DEBUGWND=$74002E
[22:10:36.200] Windows version: 6.2.9200 (NT platform: Yes)
[22:10:36.203] 64-bit Windows: Yes
[22:10:36.209] Processor architecture: x64
[22:10:36.212] User privileges: Administrative
[22:10:37.660] 64-bit install mode: No
[22:10:37.674] Created temporary directory: C:\Users\CAOSHU~1\AppData\Local\Temp\is-5AOTJ.tmp
[22:10:37.717] InitializeSetup raised an exception (fatal).
[22:10:37.725] Exception message:
[22:10:37.734] Message box (OK):
Access violation at address 006043C0 in module 'setup.tmp'. Read of address 00000014.
[22:11:03.501] User chose OK.
[22:11:03.515] Deinitializing Setup.
[22:11:04.424] *** Setup exit code: 1
Perhaps the way I compiled inno setup has some problems. I need not use XE6? But how to debug and figure out where the problem is？
It is not some code which crashes when it runs. It is a setup.exe which created by inno setup.
The value returned by InitializeSetup() is undefined.
function InitializeSetup(): Boolean;
begin
result := true;
end;
You get an undefined behaviour because of this. If most of the time the result will be false (last 8 bits of RAX == 0), this is not always the case and you'll get a seriously "hard to understand" issue, particularly when, for no reason, it'll work.
Why does the Delphi compiler ignore this missing parenthesis?
function Test: Boolean;
begin
Exit(True; // <-- eek! it compiles...
end;
I found some of my code looking like this and first thought that Delphi ignores my unit - but it just ignores this type of syntax error. So now of course I want to know why.
I'm guessing Exit is considered a token unto itself, and as such anything defined within the same scope after Exit is simply ignored by the compiler (since it cannot execute those instructions anyway).
Maybe the compiler is thinking that either
1. There is an Exit by itself, or
2. There is an Exit with a set of parentheses ().
If it doesn't find #2 it goes to #1.
How can I find in Visual C++ if an OCX file (for example flash.ocx) is registered or not?
If you mean from the .ocx file itself, you've probably got two options:
Read the type library from the .ocx, parse out the object and interface UUIDs and see if they all exist in the registry under HKCR\CLSID, HKCR\TypeLib etc.
Loop through all registered objects in the HKCR\CLSID in the registry and see if any of them reference your .ocx as their InprocServer32 reference. You may need to do path and environment variable expansion on the path you read in order to test the match.
The first method won't necessarily tell you if it's the same version of the .OCX installed, though (although you can check the path on disk for each). The second is unfortunately going to be very slow.
It's probably simplest to just re-register the .ocx I'd think.
You can check if the clsid of the ocx is under HKEY_CLASSES_ROOT.
Here is a simple code I use to detect on runtime to check if a specified ocx is registered.
#include<windows.h>
...
//Check if an ocx is resisted, and push warning
HKEY subKey = NULL;
LONG ret = RegOpenKeyEx(HKEY_CLASSES_ROOT, _T("CLSID\\{XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX}"), NULL, KEY_QUERY_VALUE|KEY_WOW64_32KEY, &subKey);
//Note that some CLSID of versioned ocx is under HKEY_CLASS_ROOT\TypeLib\{XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX}
if(ret != ERROR_SUCCESS)
{
TCHAR message[512];
FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM,NULL,ret,0,message,512,NULL);
CString msgStr = message;
#ifdef DEBUG //Extra message on DEBUG mode
AfxMessageBox(msgStr.GetBuffer());
#endif
AfxMessageBox(_T("OCX not registered"), MB_OK);
}
else
{
AfxMessageBox(_T("OCX is registered"), MB_OK);
RegCloseKey(subKey); //Remember to close opened key handle.
}