Is there a way in windbg to create a break point that will fire when a certain parameter is passed on the stack? - windbg

I'm trying to track down who is making an allocation of a certain size, and I tried using the user mode stack trace db (gflags +ust), but due to FPO I can't see the entire stack. So instead I wanted to set a breakpoint on RtlAllocateHeap when it makes the allocation size I'm looking for. The only problem is I can't seem to find out a way to get this to work.
I initially tried using #esi since it looked like the third parameter was being passed using this register, but it doesn't appear that's always the case. So then I tried #ebp-c to give me the third parameter, but that doesn't appear to always work, so I tried #esp+14 and that didn't work either.
No matter what I do I can't seem to find a way to get this to actually fire when I want it to. It seems like this should work, but I'm guessing it is using leaf function optimizations in certain cases which is preventing me from being able to do this.
Anyone have any ideas on how to get this to work.
Heap stack trace:
0:013> !heap -p -a 0c060710
address 0c060710 found in
_HEAP # 1420000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0c0606f8 09c3 0000 [00] 0c060710 04e00 - (busy)
77abb234 ntdll!RtlAllocateHeap+0x00000274
75ee404b ole32!CRetailMalloc_Alloc+0x00000016
76454557 OLEAUT32!APP_DATA::AllocCachedMem+0x00000060
7645476a OLEAUT32!SysAllocStringByteLen+0x0000003d
764547bf OLEAUT32!ErrStringCopyNoNull+0x00000016
764547e3 OLEAUT32!VariantCopy+0x0000007f
Break points tried:
bp ntdll!RtlAllocateHeap "j #esi == 0x4e00 ''; 'gc'"
bp ntdll!RtlAllocateHeap "j poi(#ebp-c) == 0x4e00 ''; 'gc'"
bp ntdll!RtlAllocateHeap "j poi(#esp+14) == 0x4e00 ''; 'gc'"

I think I have tested this:
Break on allocation size == 1303
bp ntdll!RtlAllocateHeap "j(poi(#esp+c) = 0x1303) 'k';'gc'"

Use poi(#esp+c)
At the first instruction of the function, you do not have EBP. So the structure on the stack for cdecl and stdcall is
<return address>
<First arg>
<second arg>
etc.

Related

FBD for TwinCat Beckhoff... Function Block Input Output How is this working

Seems IW_PR_Schrittnummer is only referenced in 3 spots... where it's declared and where its read in the fbd routine... I guess what I'm asking is something writing a number to this variable... or what? If so how would I find it... also what is the action being performed by this first function block? looks like there are 4 inputs, Auto, is Auto Active, does tasknumber = 0, and is Press Free. if all 4 of these are true... then End Auto. Does that sound right??? someone else programmed this for a job that does work. The tags are in German.
1st FBD
Variable Reference
Variable Declaration
2nd fbd just for reference
The IW_PR_Schrittnummer is linked to input I/O using AT %ID716 command. So it gets its value from I/O memory. That basically means that "take this value from input memory at address 716 and the size is D (double word, 32 bits).
I'm not sure how you can check what is in that address when it's defined with direct addressing like this. Hopefully someone else knows a good tip for this!
More info about addresses: https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_plc_intro/18014401038842507.html&id=6547931155168793261
More info about addresses: https://help.codesys.com/webapp/_cds_at_declaration;product=codesys;version=3.5.15.0
That logic from your 1st image works as you said. So AutoFinde will be TRUE, if Auto, AutoAktiv, IstFrei are all TRUE and the input IW_PR_Schrittnummer is 0. Otherwise the AutoFinde will always be FALSE.

unexpected frame appears onto another frame after an event

I'm using a character application. In the first page, there is a frame f-selection where the search fields are entered. When I search for something and open some other frames in that search, then I press F10 which is for opening another frame, the new frame opens but f-selection also appears on it. I'm suspecting this code makes it pop up again:
else assign ll-lgst-key1:SENSITIVE in frame f-selection = TRUE
ll-lgst-key2:SENSITIVE in frame f-selection = FALSE
because when I comment these lines, the frame doesn't pop up. But then I can't use these fields at the first frame where I should, too. I don't know why this code is called again; but is there anything else I can do to fix this issue? I tried to write hide frame f-selection everywhere possible but it doesn't work.
That snippet of code is making "key1" of your frame sensitive. In order to be sensitive it needs to pop up...
So the issue is why is that block of code executing? You say "I don't know why this code is called again". Neither will anyone else because you have shared such a tiny little bit of the overall code. Apparently the flow of control is taking you through that block so you should work on understanding why that is. You might try using the debugger to step through the code execution or you could insert some old fashioned MESSAGE statements to get to the bottom of it.
If you want to kludge around the problem you could wrap that bit of code in conditional logic. Define and set a variable that determines the desired state of the f-selection frame and use that to control the sensitivity logic:
define variable f-shouldBeVisible as logical no-undo.
if .... then
f-shouldBeVisible = yes.
else
f-shouldBeVisible = no.
...
else
do:
if f-shouldBeVisible then
assign ll-lgst-key1:SENSITIVE in frame f-selection = TRUE
ll-lgst-key2:SENSITIVE in frame f-selection = FALSE
.
end.
Of course that looks kind of silly -- but it is just an example with grossly over-simplified logic.
OTOH if you know enough to set the variable you ought to be able to figure out why the ELSE branch is executing. But maybe it is a useful first step.

SB37 JCL error to small a size?

The following space allocation is giving me an sB37 JCL error. The cobol size of the output file is 100 bytes and the lrecl size is 100 bytes. What do you think is causing this error? I have tried increase the size to 500,100 and still get the same error.
Code:
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DCB=(LRECL=100,BLKSIZE=,RECFM=FBM),
// SPACE=(CYL,(10,5),RLSE)
Try to increase not only the space, but the volume as well.
Include VOL=(,,,#) in your DD. # is the numbers of values you want to allocate
Ex: SPACE=(CYL,(10,5),RLSE),VOL=(,,,3) - includes 3 volumes.
Additionally, you can increase the size, but try to stay within reasonable limits :)
The documentation for B37 says the application programmer should respond as indicated for message IEC030I. The documentation for IEC030I says, in part...
Probable user error. For all cases, allocate as many units as volumes
required.
...as noted in another answer. However, be advised that the documentation for the VOL parameter of the DD statement says...
If you omit the volume count or if you specify 1 through 5, the system
allows up to five volumes; if you specify 6 through 20, the system
allows 20 volumes; if you specify a count greater than 20, the system
allows 5 plus a multiple of 15 volumes. You can override the maximum
volume count in data class by using the volume-count subparameter. The
maximum volume count for an SMS-managed mountable tape data set or a
Non-managed tape data set is 255.
...so for DASD allocations you are best served specifying a volume count greater than 5 (at least).
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DCB=(LRECL=100,BLKSIZE=,RECFM=FBM),
// SPACE=(CYL,(10,5),RLSE)
Try this instead. Notice that the secondary will take advantage of a large dataset whereas without that parameter the largest secondary that makes any sense is < 300. Oh, and if indeed it is from a COBOL program make sure that the FD says "BLOCK 0"!!!!! If it isn't "BLOCK 0" then you might not even need to change your JCL because it wasn't fixed block machine. It was merely fixed and unblocked so the space would almost never be enough. And finally you may wish to revisit why you have the M in the RECFM to begin with. Notice also that I took out the LRECL, the BLKSIZE and the RECFM. That is because the FD in the COBOL program is all you need and putting it in the JCL is not only redundant but dangerous because any change will have to be now done in multiple places.
//OUTPUT1 DD DSN=A.B.C,DISP=(NEW,CATLG,DELETE),
// DSNTYPE=LARGE,UNIT=(SYSALLDA,59),
// SPACE=(CYL,(10,1000),RLSE)
There is a limit of 65,535 tracks per one volume. So if you will specify a SPACE that exceeds that limit - system will simply ignore it.
You can increase this limit to 16,777,215 tracks by adding DSNTYPE=LARGE paramter.
Or you can specify that your dataset is a multi volume by adding VOL=(,,,3)
You can also use DATACLAS=xxxx paramter here, however first of all you need to find it. Easy way is to contact your local Storage Team and ask for one. Or If you are familiar with ISPF navigation, you can enter ISMF;4 command to open a panel
use bellow paramters before hitting enter.
CDS Name . . . . . . 'ACTIVE'
Data Class Name . . *
It should produce a list of all available data classes. Find the one that suits you ( has enougth amount of volume count, does not limit primary and secondary space

Uitable, cellSelectionCallback and modifying dataset

My code is really too long to be posted here, even by little portions. So I will just ask for one or two things :
It appears to me that when modifying the 'Data' property of an uitable 'ht' :
set(ht, 'Data', something);
that the "cellSelectionCallback" routine is triggered (as the selection is very likely to have changed, indeed), but not immediatly after the dataset is modified.
Is this true ?
Is there any way to prevent such a behavoir ?
Thanks !
I have code using a uitable, e.g:
tbl = uitable('Parent', fh, 'CellSelectionCallback',{#cell_select_callback fh});
I did a quick experiment and when using set(tbl,'Data',my_data) the callback is triggered only if the set causes the selected cell(s) to change, and this happens immediately (as far as I can tell - I saw no appreciable delay).
To stop that happening you could just unset the CellSelectionCallback property, change the data, and then reset CellSelectionCallback.
I had the same issue. Was getting index out of bounds warnings. To get rid of those I used this in my CallSelectionCallback:
if ~isempty(eventdata.Indices)
// all the code
end
When the set command triggers the CallSelectionCallback the eventdata.Indices is empty.
A similar possibility to Sebastien's answer is to put this in your cellselectioncallback function:
function output = mycellselection(source,event)
if isempty(event.Indixes)
output = [];
return
end
% rest of your code for cell selection
end
If you don't have any output needed, you can just remove it. I just put it in there to remind you that you have to assign a value to any outputs.

PLC View Bit of an address

I am using a Omron PLC and looking at this bit in memory
CIO1767 BIT 14 In binary view
Its either going to be a 1 (on) or 0 (off)
I would like to put in the ladder logic. If this bit is on do ....
But Dont know how to write that bits address.
First do i have to use a compare to see if its 1 or 0
or
can i do a normally open and it give me NC if its 0?
Also if unclear, how do i write this bit i was trying CIO1767.14 but that does not seem to work?
thanks
glen
Figured it out, You can use a NO or NC operation. For this instance you have to place the operation, then for address just put CIO . Then it will give you another pop up asking for the data or location here you would put 1767.14. Thats it!