| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | DOSFINDFIRST HELP |
I am having a very mysterious problem with the following bit of code:
These two routines are only a small portion of another larger program.
This code totally locks up the machine that it is running on about
once every four times it is run. It runs perfectly when it does not
crash. I have traced the code under the debugger and found no bad
parameters, no bad pointers, no logic problems. I can't trace the
crash under the debugger because when it DOES crash under the
debugger, the whole system goes down with it. This really screws up
the whole kernal. CTL-ALT-NUMLOCK-NUMLOCK doesn't even evoke a response.
I have run the code with detailed trace statements added and found that
it crashes the system in two places. Sometime inside the call to
DosFindFirst, and other times inside DosFindNext. Trace statements
around all system calls verify this. I just can't find anything wrong,
but there has to be something wrong. It TOTALLY hangs the system!
What I am asking for is this: IS there anyone who knows of any system
bugs (under 2.1 with LS 3.0) with the DosFind??? functions? Any
special circumstances that I am not aware of? Something is slowly
corrupting the system in this code. It will even cause the system
to hang other programs after it has run successfully somtimes. A reboot
always makes the system stable again the other programs running on it.
Keep in mind that this code has been debugged and does operate
correctly, execept for the occasional unexplained system crashes.
Your expert advice / wisdom is greately appreciated in advance if
you can tell me anything about why this code might be crashing.
I am at my wits end on this one..... I haven't had a bug I couldn't
find for years, and this one has me stumped. BTW, the stack is 32k
and is most definitely NOT even getting close to running out
due to the recursion...
---------8<----cut here----------------------8<--------------------
static void ProcessUser(char *ServerName, char *UserName)
{
char LSFAR * LSPTR Buff;
struct user_info_2 *UserInfo2;
PUCHAR UIBuff;
USHORT BuffLen;
USHORT TotalAvailable;
APIRET rc;
char HomeDir[PATHLEN + 1];
UCHAR ServerResource[PATHLEN+1];
UCHAR ServerPath[PATHLEN+1];
UCHAR HomeServer[UNCLEN + 1];
UCHAR UserComment[MAXCOMMENTSZ + 1];
UCHAR ScanDrive[3];
UCHAR ServerDrive;
PUCHAR ParsePtr;
ULONG AllocBytes;
USHORT Permission;
/* now we will get more detailed information for each user account */
/* again, the first call gets the size of the buffer needed */
rc = NetUserGetInfo(ServerName, UserName, 2, NULL, 0, &TotalAvailable);
if (rc && rc != ERROR_MORE_DATA && rc != NERR_BufTooSmall) {
sprintf(temp, "Getting User Info for %s on Server %s : return
code = %d",
UserName, ServerName, rc);
DoError(temp);
}
else {
/* allocate storage for the buffer */
BuffLen = TotalAvailable;
UserInfo2 = (struct user_info_2 *)malloc(BuffLen);
if (UserInfo2 == NULL) {
DoFatalError("Memory Allocation Error : UserInfo2 Buffer");
}
Buff = (char LSFAR * LSPTR)UserInfo2;
/* get the detailed user account data */
/* we are looking for the user's home directory in particular */
rc = NetUserGetInfo(ServerName, UserName, 2, Buff, BuffLen,
&TotalAvailable);
if (rc) {
sprintf(temp, "Getting User Info for %s on Server %s : return code =
%d",
UserName, ServerName, rc);
DoError(temp);
}
else {
/* copy the home directory string in order to avoid a protection fault
*/
UIBuff = (PUCHAR)UserInfo2->usri2_home_dir;
strcpy(HomeDir, UIBuff);
if (strlen(HomeDir) > 0) { /* skip users with no
..
--- WILDMAIL!/WC v4.11
* Origin: Freezing Point BBS - WDNet HQ - Mpls MN: (1:282/85.0)SEEN-BY: 12/2442 54/54 620/243 624/50 632/348 640/820 690/660 711/409 410 413 SEEN-BY: 711/430 807 808 809 934 942 949 712/353 623 713/888 800/1 @PATH: 282/85 1 270/101 396/1 3615/50 229/2 12/2442 711/409 54/54 711/808 809 @PATH: 711/934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.