I am a scsi driver developer.
I write a user space program to get data from driver via CreateFile.
It works ok when testing in 32 bit windows environment but in 64 bit the following error appears:
CreateFile return -1. GetLastError() would return 2. (ERROR_FILE_NOT_FOUND)
I have called IoCreateSymbolicLink when driver initializes and
it returns success when I am using windbg to see debug output.
Anyone has met this kind of problem?
Related
Following on from my last question on implementing the Microsoft Active Script debugger interfaces on 64 bit windows. I have come across another intractable problem.
This time it's with IActiveScriptDebug which doesn't seem to work in its 64 bit incarnation.
The code in question is when attempting to set breakpoints using the code from MS example debugger code (converted to Delphi).
Href:=FEngine.QueryInterface(IID_IActiveScriptDebug,FdebugEngine);
Href:=FdebugEngine.EnumCodeContextsOfPosition(0,Line,LineLen,edcc);
if IEnumDebugCodeContexts(edcc).Next(1,dcc,numFetched) = S_OK then
Href:=dcc.SetBreakPoint(BREAKPOINT_ENABLED);
Where Fengine is the IactiveScript Language engine and FdebugEngine is the returned IActiveScriptDebug object and edcc is a IEnumDebugCodeContexts;
IID_IActiveScriptDebug is set to the IID_IActiveScriptDebug64 GUID for 64bit windows and IID_IActiveScriptDebug32 for 32 bit windows. In both cases a valid debug engine is returned.
Compiled for 32 windows, this code works fine. I can set breakpoints and the get the callbacks on breaks.
Compiled for 64 bit, FdebugEngine.EnumCodeContextsOfPosition returns a "Catastrophic failure" Hresult.
Any ideas why the 64 bit code produces this error ?
So after much chasing my tail and the lack of responses from this forum, I have come to the conclusion that the 64 bit version of the Active script debugger is broken and there is no prospect of it getting fixed as it seems to be deprecated.
So I leave this here as a warning to anybody wanting to implement this feature and let them know not to waste their time.
Good morning,
My problem is that I have a main program that calls a service (created by me, too) that it does is create some files subsequently sent to the print queue in Windows, the problem is when this program is executed by a windows 8 taking all permits and to run as administrator does not work, or prints or anything and gives the following error "no currently no default printer selected" (error completely random because if there default printer selected).
The service operation is simple, select the printer that there stored in the database and if this printer is the same as Windows sends the generated file in windows 7, xp, vista and other operating systems prior to Windows 8 functions perfectly.
Onsite windows 8 is 64 bits.
Thank you
I have already solved, I passed the source code to a normal program (without being a windows service) and it works perfectly.
I am using a COM interface to connect to an external device that is connected to the computer running the software via TCP/IP. I am posting this, because on one system this connection fails, mysteriously.
From the manufacturer, I have received an instrument.dll and an instrument.tlb. Unfortunately, details and code are subject to a confidentiality agreement, so I can only provide pseudocode.
I have two minimal examples, one on Free Pascal (the important one, because this is where I am developing):
uses
Instrument_TLB; // Imported via the Lazarus "Import Type Library" function from the .tlb or the .dll
[...]
procedure TForm1.FormCreate(Sender: TObject);
begin
AInstrument := CoInstrument.Create;
if AInstrument.Connected then ...
end;
and one on Visual Basic, provided by the manufacturer:
Private Sub Form_Load()
Set theInstrument = New Instrument
If theInstrument.Connected Then ...
End Sub
This VB6 project has the instrument.dll as a reference.
The behaviour on different computers is as follows (supplemented with information from Sysinternals Process Explorer):
System A (Windows XP, 32bit, used for compilation): Both the FP and the VB executable work as expected, a connection can be established. In Process Explorer, both executables have one thread with instrument.dll and the TCP/IP connection can be seen to be up.
System B (Windows 7, 64bit): Both the FP and the VB executable work as expected, a connection can be established. Process Explorer was not used.
System C (Windows 7, 64bit): The VB executable works as expected, a connection can be established. In Process Explorer the VB executable has one thread with instrument.dll and the TCP/IP connection can be seen to be up. The FP executable can NOT connect, there are two threads with instrument.dll and no TCP/IP connection seen in Process Explorer.
I know that based on the little information I am able to give, no one can come up with a "solution" - however, advice on how to investigate this problem further, what tools to use for debugging would be highly appreciated!
Thanks for your time.
It turned out that the registry on system C contained several entries on how to connect to the instrument, and in one, there was a slightly wrong IP address. I do not know why this key was used by my 32bit FP software and another one by the 32bit VB6 test application, but changing the IP address was one factor.
The other factor was to run the software in compatibility mode for Windows 7 on Windows 7 SP1. I don't know why that is necessary (because it works without compatibility mode on Windows SP1 on system B), but I would like to get rid of it asap ...
I have one executable. Exe is prepared from Delphi version 5 as code is written in Delphi. This exe working successfully on Windows XP, Windows 7 with 32 bit operating system. But same executable not working on Windows 7 with 64 bit operating system. It will throw following error code Exception code: 0xc0000005.
The only option is to re compile the Delphi code and make it compatible to Windows 7 64 bit operating system.
I have Google but do not find any suitable article. Therefore, can someone please help me out to resolve this issue.
I have good idea to make executable compatible for 32 and 64 bit but only in .NET Framework. So Please help me.
That error code is the NTSTATUS code for an access violation. For you to see that error code typically means that your application has raised an access violation during initialization. Once the Delphi RTL has initialized then those errors are converted into native Delphi EAccessViolation errors. So with high probability this is an error during initialization, possibly related to the way you link to or use a dependent module.
In order to solve the problem you need to do some debugging. The first thing I would do is to use Dependency Walker in profile mode to run your application. This will give you diagnostics of the load of your process at some point, presumably during the load an initialization of a module, you will see an error. Hopefully this will lead you to a solution.
Programs built with Delphi 5 do run on 64 bit Windows. You have an error in your program that needs debugging. Simple as that. Not the easiest error to debug, but it's still just a debugging exercise with your code.
i have
Run time Error 216 at ADDRESS
when registering a 64 bit dll built with Delphi XE2 (I have Update 3).
from command prompt I do (note: system32 folder contains the 64bit exe!)
c:\windows\system32\regsvr32.exe My64bitdll.dll
and after a "dll succesfully installed message"
i have the runtime error.
I would like to debug the registering process, somehow using Run/Parameters/host.
Could anyone post the correct procedure? In some other questions like this one a bug is mentioned, but it seems fixed now, i have a delphi build older than this one.
Update:
Also any comment on the RunTime error is welcome.
Load the DLL project.
Modify run parameters (Run | Parameters) to specify host app as regsvr32. Note that you may need to use C:\Windows\sysnative path to defeat the 32 bit file system redirector.
Include path to DLL as command line arguments.
Perhaps enable Debug DCUs, in case the error is raised in the Delphi COM self-registration code.
Then debug the DLL like any other DLL.
Runtime error 216 is an access violation.
1) this runtime error may be just program exit. For example would you debug internals of DllMain, you can easily get past exit point and try to trace ended DLL, which would through RE. Process exit is not looking just like return from subroutine - but rather as a call to special system API function. But debugger does not understand it and continues to trace now dead project.
2) i see not point in using RegSvr32.exe or TRegSvr.exe for debuging. All RegSvr32 does is calling predefined function from DLL. Do you debug your DLL or RegSvr32 itself ?
2.1) If latter - i heard there are sources of RegSvr32, and probably there are debug symbols, but some Microsoft debugger to be used.
2.2) If former, then there should be now difference how to call those functions and you only have to debug those functions. Just take any code from File not found when registering DLL with TFileRun and regsvr32 and use it as host.